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Call for Papers and Participation: 

Micro-Kernels and Other Kernel Architectures 

Sheraton Seattle Hotel and Towers, Seattle, Washington, April 27 -28, 1992 

The USENIX Association’s workshop on Micro-Kernels and other Kernel Architectures is 
aimed at comparing and contrasting existing micro-kernels and their macro-kernel counter¬ 
parts. Industry pundits are c laiming that microkernel technology is the next step in kernel 
design. This workshop intends to make a detailed technical investigation of the microkernel 
technology to discover whether the claims have merit or are just this year's buzzword. The 
intent of the workshop is to identify micro-kernels strengths and weakness in comparison 
to each other and to the macro-kernels that they hope to replace. The comparisons will 
include functionality, modularity, ease of extension, maintainability, and performance. 

The first day of the workshop will be devoted to talks of a tutorial nature on currently 
important microkernels and other kernels. Already committed are talks on Mach. Amoeba. 
Chorus, and Plan 9. Other talks will be added. 

The second day will be devoted to papers on all aspects of microkernels or kernel architec¬ 
ture. Papers are being solicited in areas including but not limited to: 

• Distribution 

• Performance 

• Fault tolerance 

• Multiprocessing 

• Scalability 

• Real-Time on Micro-Kernels 

If you are interested in submitting papers for either day. please send an extended abstract 
with an outline of your paper (email preferred) to the program chair (Lori Grob). 

Program Committee: 

Lori S. Grob. Program Chair 
Chorus systemes 
grob@chorus.fr/grob@usenix.org 

Edward D. Lazowska 
University of Washington 

Robbert van Renesse 

Cornell University/Vrije Universiteit 

Avadis Tevanian. Jr. 

NeXT Computer. Inc. 

Dates to Remember: 

Abstracts Due: January 10.1992 

Notification to Authors: February 14.1992 
Papers Due: March 13.1992 


September/October 1991 
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USENIX Mach Symposium 

Monterey, California, November 20-22, 1991 


The Association is pleased to announce the 
Second USENIX Mach Symposium to be held at 
the Doubletree Hotel at Fisherman’s Wharf, 
Monterey, CA, on November 20-22, 1991. 

Mach has been developed by Carnegie Mel¬ 
lon University as a thoroughly modern operating 
system. It provides a few well-defined abstractions 
(e.g., ports, memory objects, tasks and threads) 
that are used to build all system services. Tradi¬ 
tional operating system functions, such as mem¬ 
ory management, can then be implemented out¬ 
side the kernel. As a result, the kernel can 
become smaller, faster, more robust and easier to 
secure. 

Interest in and use of Mach has increased 
explosively, especially in its guises as OSF/1 and 
“the micro-kernel.” This symposium examines 
current Mach development in four ways: 

Tutorials, to teach the theory and practice of 
advanced Mach features such as IPC and external 
memory management; 

Technical Sessions, in which workers in the 
field present the results of their latest efforts; 

Speakers, analyzing the state of the art in 
operating system development and 

Work-in-progress Pesentations, in which 
workers discuss their current projects. 

The keynote speaker will be Professor John 
Ousterhout, of the University of California at 
Berkeley, who will present a talk on the direction 
of operating systems research. 


Program Committee 

Alan Langerman, 

Chairman Encore Computer Corporation 


Larry Allen 
Nawaf Bitar 
Susan LoVerso 
Melinda Shore 
Michael Young 


Open Software Foundation 
Hewlett-Packard Company 
Encore Computer Corporation 
Cornell University 
Transarc Corporation 


Registration Information 

Register in advance to receive the lowest 
rates. Attendance is limited in the Tutorial pro¬ 
gram and pre-registration is strongly recom¬ 
mended. You may register for only the tutorial 
program, only the two-day technical sessions pro¬ 
gram, or both programs. For further information, 
please contact the usenix Conference Office. 


Tutorial Program 
November 20, 1991 

The Symposium will offer a two part tutorial 
session on advanced servers and external memory 
managers in Mach 3.0 oriented towards program¬ 
mers who already have some familiarity with us¬ 
ing Mach IPC and VM. The tutorial has been 
developed specially for this symposium, and it is 
offered as a single, full-day class. It will explore 
concepts and rationale as well as real examples. 

Morning Tutorial Session: 

Writing a Multi-Threaded Mach 3.0 Server 
Instructor: Richard P. Draves, Carnegie Mellon 
University 

This tutorial teaches the student how to write 
a multi-threaded Mach 3.0 server. It assumes 
some familiarity with previous versions of Mach 
IPC and the C-Threads library, or equivalent 
systems. The tutorial presents a small multi¬ 
threaded server that can be used as a template for 
real applications. The presentation highlights the 
new Mach 3.0 features that allow the develop¬ 
ment of robust, high performance, multi-threaded 
servers. 

Afternoon Tutorial Session: 

Mach External Memory Managers: Principles and 
Practice 

Instructor: David L. Black, Open Software Foun¬ 
dation 

This tutorial teaches the student how to write 
an external memory manager. It assumes a fa¬ 
miliarity with Mach 3.0 IPC topics (e.g., from the 
morning tutorial), and the C-Threads library. Em- 
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phasis is placed on the role and responsibilities of 
an external memory manager in the Mach system. 
The tutorial includes an example external mem¬ 
ory manager. 

Tentative Technical Program 

Thursday, November 21 

9:00 - 10:00 

Opening Remarks - Alan Langerman, Program 
Chairman 

Keynote: Operating Systems Research: Fads and 
True Value Professor John Ousterhout, Uni¬ 
versity of California - Berkeley 

10:30-12:00 Mach 3.0 

A Fast Mach Network IPC Implementation 

Joseph S. Barrera III, Carnegie Mellon Uni¬ 
versity 

Generalized Emulation Services for Mach 3.0 
-Overview , 

Experiences and Current Status 
Daniel P. Julin, Jonathan J. Chew, Carnegie 
Mellon University; Paulo Guedes, Paul Neves, 
Paul Roy and J. Mark Stevenson, Open Soft¬ 
ware Foundation Research Institute 

DOS as a Mach 3.0 Application 
Richard Rashid, Gerald Malan, David Golub, 
and Robert Baron, Carnegie Mellon University 

12:00-12:30 A New Operating System of Interest 
Speaker TBA 

12:30-2:00 Lunch on your own. 

2:00-3:30 User Memory Management 

A Causal Distributed Shared Memory Based on 
External Pagers 

Fabienne Boyer, Unite Mixte Bull-IMAG/ 
Systemes 

Supporting Structured Shared Virtual Memory Un¬ 
der Mach 

Ray Bryant, Bryan Rosenburg, Hung-Yang 
Chang, IBM T.J.Watson Research Center 

Managing Discardable Pages with an External 
Pager 

Indira Subramanian, Carnegie Mellon Univer¬ 
sity 

4:00-5:30 OSF/1 

OSF/1 Virtual Memory Improvements 


David Black, Open Software Foundation Re¬ 
search Institute; Shashi Mangalat, Encore 
Computer Corporation; Eric Sheinbrood, 
Workstation Solutions, Inc.; Jeff Carter, 
George Feinberg, Rod MacDonald, Jim Van 
Sciver and Ping Wang, Open Software Foun¬ 
dation Development 

Parallelizing Signal Handling and Process Man¬ 
agement in OSF/1 

Don Bolinger and Shashi Mangalat, Encore 
Computer Corporation 

Mach Resource Control in OSF/1 
David W. Mitchell, Open Software Foundation 
Development 

Friday, November 22 

9:00-10:30 Mach Interfaces 

Mach Interfaces to Support Guest O.S . Debugging 
Rand Hoven, Hewlett-Packard 

Kernel Support for Network Protocol Servers 
Jeffrey Heller and Franklin Reynolds, Open 
Software Foundation Research Institute 

An I/O System for Mach 3.0 

Alessandro Forin, Carnegie Mellon University 

11:00-12:30 Changes To Kernel Memory Man¬ 
agement 

Moving the Default Memory Manager Out of the 
Mach Kernel 

David B. Golub, Carnegie Mellon University 

User-Level Physical Memory Management for 
Mach 

Stuart Sechrest and Yoonho Park, University of 
Michigan 

Page Replacement and Reference Bit Emulation in 
Mach 

Richard P. Draves, Carnegie Mellon University 

12:30-2:00 “Multi-Server” Luncheon - by paid 
reservation 

2:00-3:30 Real Time, Reliability, Comparison 

Evaluation of Real-Time Synchronization in Real- 
Time Mach 

Hideyuki Tokuda and Tatsuo Nakajima, Car¬ 
negie Mellon University 

How to Design Reliable Servers using Fault Tol¬ 
erant Micro-Kernel Mechanisms 
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Michel Banatre and Gilles Muller , IRISA! 
INRIA; Pack Heng, and Bruno Roc hat, BULL 
Research 

The File System Belongs in the Kernel 
Brent Welch, Xerox Palo Alto Research Center 

4:00-5:30 Alternate Paper 


Distributed Trusted Mach Architecture 
Edward John Sebes, Trusted Information 
Systems 

4:20-5:30 Works in Progress and Closing Re¬ 
marks 


EurOpen Publications 


The following publications are available from 
EurOpen. If enough usenix members express an 
interest, we may make these publications avail¬ 
able through our office. Send email to 
office@usenix.org if you would be interested in 
such an arrangement. 


Paris 

Spring ’85 

8.20 

Copenhagen 

Autumn ’85 

16.40 

Finland/Sweden 

Spring ’87 

2.80 

Dublin 

Autumn ’87 

32.80 

Munich 

Spring ’90 

32.80 

Nice 

Autumn ’90 

41.00 

Tromso 

Spring ’90 

41.00 


Proceedings: 

Dublin 

Nijmegen 

Cambridge 


Autumn ’83 
Spring ’84 
Autumn ’84 


$ 3.28 
8.20 
8.20 


EurOpen Email Directory, 2nd edition 32.80 

(List prices are given in U.S. dollars, based on 
current exchange rates.) 


1992 USENIX Nominating Committee 


The Nominating Committee for the USENIX 
Association board of directors is comprised of: 

Marc D. Donner, IBM Research 
Andrew Hume, AT&T Bell Labs 


Peter H. Salus, Sun User Group , chairman 
Charles Sauer, Dell Computer 
Elizabeth Zwicky, SRI International 
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Call for Participation 

Symposium on Experiences with Distributed 
and Multiprocessor Systems (SEDMS III) 
March 26-27, 1992, Newport Beach, California 

In association with: 

The Software Engineering Research Center (SERC) 

In cooperation with: 

ACM SIGARCH, SIGCOMM, SIGOPS, and SIGSOFT (Pending) 
IEEE-CS Technical Committees on Distributed Processing, 

Operating Systems, Software Engineering, and Design Automation 


The goal of this symposium is to bring to¬ 
gether individuals who have built, are building, or 
will soon build distributed and multiprocessor sys¬ 
tems. SEDMS III will provide a forum for indi¬ 
viduals to exchange information on their experi¬ 
ences, both good and bad, including experiences 
with coding aids, languages, debugging and test¬ 
ing technology, reuse of existing software, and 
performance analysis. The presentations should 
emphasize the lessons learned from use of such 
systems and tools. 

Extra-long breaks between sessions and 
work-in-progress presentations will be provided 
to facilitate a workshop-like atmosphere during 
parts of the symposium. We will also have dis¬ 
cussion panels on submitted themes. 

Six copies of each submission or panel pro¬ 
posal should be sent to the program committee 
chair (address below) to arrive no later than 
November 1, 1991. Submissions of full papers are 
invited on any topics related to the theme of the 
symposium. The committee will give preferential 
consideration to submissions describing experi¬ 
ences with actual systems—papery describing 
purely theoretical work will not be accepted . Panel 
proposals should include a description of the rel¬ 
evance to the goals of the SEDMS, and the qual¬ 
ifications of the participants suggested. 

Important Dates 

Submissions due November 1, 1991 

Notifications mailed December 20, 1991 

Camera ready copy due January 24, 1992 


For further information, contact: 

General Chair 

George Leach 
AT&T Paradyne 
MS LG-133 
PO Box 2826 
Largo, FL 34649-2826 
(813) 530-2376 
reggie@paradyne. com 

Program Chair 

Gene Spafford 

Software Engineering Research Center 

Dept, of Computer Sciences 

Purdue University 

W. Lafayette, IN 47907-1398 

(317) 494-7825 

spaf@cs.purdue . edu 

Program Commitee: 


John Barr 
Motorola 

David Cohn 
Univ. of Notre Dame 

Yousef Khalidi 
Sun 

Andrzej Goscinski 
Univ. of New South Wales 

Mike O’Dell 
Bellcore 

Satish Tripathi 
Univ. of Maryland 

Howard Katseff 
AT&T 

Thomas Wilkes 
Univ. of Lowell 


Sue LoVerso 
Encore 

Dan Duchamp 
Columbia Univ. 

John Nicol 
GTE Labs 

Bharat Bhargava 
Purdue Univ. 

Marc Pucci 
Bellcore 

Elie Milgrom 
Louvain Univ., Belgium 

William Bain 
Intel 

Karsten Schwan 
Georgia Tech 
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Call for Participation: WWOS-III 

Third Workshop on Workstation Operating Systems 

April 23-24,1992 

Tbe Sheraton Royal Biscayne Beach Resort & Racquet Club • Key Biscayne, Florida 
IEEE Computer Society Technical Committee on Operating Systems and Application Environments 



The Third Workshop on Workstation Operating Systems (WWOS-Iip will bring together operating systems 
researchers, developers, and users to discuss current and emerging issues in workstation operating systems. 


The purpose of WWOS-III is to examine current controversial issues in workstation operating systems. Therefore, 
we request the submission of position statements rather than of papers reporting ongoing or completed research. We 
will give priority to those statements that tackle difficult issues, propose new directions, advocate untraditional 
approaches, or generate controversy and discussion. 


This year's workshop will encourage participants to consider whether workstation operating systems, current and 
future, can effectively address the needs of the expanding range of workstation applications, hardware and 
environments. Developers in areas including database, multi-media, security, and programming languages agree 
that workstation operating systems do not provide the services they need. While they want a workstation (their own 
machine) to be something more than just a PC or a time-shared machine, they often do not agree on what else they 
want. The controversial issues include: 

• Automatic adaptive scheduling vs. application-controlled scheduling. 

• Machine-independent system abstractions vs. hardware-specific events and interrupts. 

• Dynamic binding and loading. 

• Synchronized updates to secondary storage vs. write-behind buffering. 

• Local workstation autonomy vs. central control of the network resources. 

• Multi-threaded programming models vj. extracting concurrency from single-threaded programs. 

• Direct access to graphics or network hardware vs. software insulated from hardware details. 

To assure a productive workshop environment, attendance will be limited to 60 workers active in the field. Each 
potential participant must submit eight copies of a 1-4 page position statement describing his or her interests and 
potential contribution to the workshop. Selection for participation will be based on the relevance, quality, vitality 
and debatability of the statements. Our choice of presenters, as well as the selection of topics and participants for 
various panels, will also be based on the position statements. 

Position statements will be printed and made available to participants before the workshop. Authors of particularly 
good submissions will be invited to write extended or improved versions for inclusion in a proceedings to be 
published after the workshop. 

General Chair: Joseph Boykin, 

Encore Computer Corp. 

Program Chair: Anita Borg, 

DEC Western Research Lab. 

Program Committee: 

Stella Atkins, Simon Fraser University 
Roy Levin, DEC Systems Research Center 
John Ousterhout, 

University of California - Berkeley 
Michael L. Powell, Sun Microsystems 
Dave Presotto, AT&T Bell Laboratories 
M. Satyanarayanan, Camegie-Mellon University 
Marc Shapiro, INRIA 

Submission deadline: December 1,1991 
Notification of acceptance: February 1,1992 


Registration including a copy of the proceedings 

Pre-registration (before Feb. 28) 

On-site 

Computer Society Member 

$270 

$320 

Non-member 

$340 

$395 

Student Member 

$150 

$150 


Registration includes all meals; Lodging: $88 per night, single- or double-occupancy 


Send submissions or questions to: 

Anita Borg/WWOS-III Program Chair 
Digital Equipment Corp. Western Research Lab. 
250 University Avenue 
Palo Alto, CA 94301 

(415) 617-3315 or borg@decwrl.dec.com 

For registration information: 

Joseph Boykin/WWOS-m General Chair 
Encore Computer Corp. 

257 Cedar Hill Street 
Marlborough, MA 01752 

(508) 460-0500 or boykin@encore.com 
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Calendar of UNIX Events + 


1991 Oct 21-25 

IEEE 1003 

Parsippany, NJ 

1991 Oct 21-25 

COMDEX 

Las Vegas, NV 

1991 Oct 30-Nov 1 

UNIX EXPO 

NY, NY 

1991 Oct 31 

Sun User Group 

The Netherlands 

1991 Nov 4-8 

ISO/IEC CJT1 SC22 WG15 

Stockholm, Sweden 

1991 Nov 14 

APP/OSE Users Forum 

NIST, Gaithersburg, MD 

1991 Nov 14-15 

JUS Symposium 

Osaka, Japan 

1991 Nov 20-22 

*Mach Symposium 

Monterey, CA 

1991 Nov 27-29 

AFUU 

Grenoble, France 

1991 Dec 3-4 

UNIX Fair ’91 

Tokyo, Japan 

1991 Dec 7-10 

Sun User Group 

San Jose, CA 

1991 Dec 9-13 

DECUS 

Anaheim, CA 

1991 Dec 16-18 

UKUUG 

Edinburgh, UK 

1991 Jan 13-17 

IEEE 1003 

Irvine, CA 

1992 Jan 20-24 

USENIX 

San Francisco, CA 

1992 Jan 22-24 

UniForum 

San Francisco, CA 

1992 Mar 4-7 

Computers in Libraries 

Westport, CT 

1992 Mar 11-18 

CeBIT 92 

Hannover, Germany 

1992 Mar 24-27 

AFUU 

Paris, France 

1992 Mar 26-27 

*SEDMS III 

Newport Beach, CA 

1992 Apr 6-9 

EurOpen/U SENIX 

Jersey, UK 

1992 Apr 6-10 

IEEE 1003 

Atlanta, GA 

1992 April 27-28 

*Micro-Kernel 

Seattle, WA 

1992 May 4-8 

DECUS 

Atlanta, GA, 

1992 May 18-22 

ISO/IEC CJT1 SC22 WG15 


1992 Jun 2-4 

UNIX EXPO West 

Anaheim, CA 

1992 Jun 8-12 

USENIX 

San Antonio, TX 

1992 Jun 22-24 

Sun User Group 

Washington, DC 

1992 Summer 

UKUUG 

Belfast, Northern Ireland 

1992 Jul 13-17 

IEEE 1003 


1992 August 

*C++ 


1992 Fall 

*Security III 


1992 Sept 8-11 

AUUG 

Melbourne, Australia 

1992 Oct 6 

ISO/IEC JTC1 SC22 WG15 

Denmark 

1992 Oct 19-23 

IEEE 1003 


1992 Oct 26-30 

Interop 

San Francisco, CA 

1992 Nov 25-29 

EurOpen/UniForum 

Amsterdam, The Netherlands 

1992 Dec 

UKUUG 

Manchester, UK 

1993 Jan 11-15 

IEEE 1003 


1993 Jan 25-29 

USENIX 

San Diego, CA 

1993 Mar 16-18 

UniForum 

San Francisco, CA 

1993 Mar 24-31 

CeBIT 93 

Hannover, Germany 

1993 Apr 5-19 

IEEE 1003 


1993 Apr 26-30 

EurOpen 


1993 Jun 21-25 

USENIX 

Cincinnati, OH 

1993 Oct 25-29 

Interop 

San Francisco, CA 

1993 Autumn 

EurOpen/UniForum 

Utrecht, The Netherlands 

1994 Jan 17-21 

USENIX 

San Francisco, CA 

1994 Mar 16-23 

CeBIT 94 

Hannover, Germany 

1994 Mar 23-25 

UniForum 

San Francisco, CA 

1994 Jun 6-10 

USENIX 

Boston, MA 

1994 Sep 12-16 

Interop 

San Francisco, CA 

1994 Autumn 

EurOpen/UniForum 

Utrecht, The Netherlands 

1995 Jan 16-20 

USENIX 

New Orleans, LA 

1995 Feb 21-23 

UniForum 

Dallas, TX 

1995 Jun 19-22 

USENIX 

San Francisco, CA 


'Compiled with the assistance of Alain Williams of EurOpen and Susanne Wilhelm of Windsound Consulting. 
*USENIX workshops, symposia, and mini-conferences 
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Book Review 

Open Systems: A Business Strategy for the 1990s 
by Pamela A. Gray 

(McGraw-Hill, ISBN 0-07-707244-8, 263 pages $40.95) 


Reviewed by Jeff Haemer, 

Interactive Systems 

Open Systems: A Business Strategy for the 
1990s is quite a good book. But you may find it 
tedious, boring, and largely free of useful infor¬ 
mation. I’ll complain for a minute, then explain 
why my complaints are irrelevant and why you 
should buy a copy today. 

Chances are if you’re reading ;login :, you’re 
a UNIX programmer. And if you’ve paused to read 
this, you’re in industry. That being the case, I’d 
guess OS:ABSft-1990s won’t hold your interest. 
The book is about technological change, but it 
neither requires nor imparts a whit of technical 
knowledge about UNIX, Posix, C, or anything 
else. It contains no code, no pseudo-code, no 
algorithms. 

It does contain contemporary open systems 
graphics. You’ll see illustrations of “Systems,” 
with icons for disks, computers, and workstations, 
all connected for interoperability; Venn diagrams 
reminding us that standards overlap; block dia¬ 
grams of layered, open architectures; figures with 
circles and clouds and bar charts and graphs with 
unit less axes. I’d guess that all the graphics were 
done on a Macintosh, which is a damning state¬ 
ment not about the book, but about UNIX. 

The text is good, the editing fair. Chapters in 
OS:ABSft-1990s are well organized and para¬ 
graphs are well-crafted, for which Pamela Gray 
deserves praise. But occasional typos, like “con¬ 
census”, indicate that the manuscript was not even 
run through a spelling checker. (Why is it that 
only computer books still have spelling errors?) 
Better editing could have fixed other minor prob¬ 
lems: the contact phone for JUS in Tokyo seems 
to have the wrong city code; Appendix 3 asserts 
that date and time formats in France are syntac¬ 
tically indistinguishable (“20.06.55” being either 
June 20, 1955 or 8:06:55 PM, which would, ad¬ 
mittedly, explain how misunderstandings can 
arise when dealing with the French); and so on. 


But OS:ABSft-1990s is not a reference book 
for programmers. It’s written for the senior man¬ 
agers, the executives, the sales and marketing and 
training departments, the “decision makers”: the 
people you have to work with who make your life 
miserable because they don’t know what’s in this 
book. For them, OS:ABSft-1990s offers five chap¬ 
ters on standards. It names major players and 
central standards, tells how the groups and stan¬ 
dards fit together, and clarifies the pressures to 
standardize. A chapter on X/Open, includes an 
eight-page, nine-point-type transcript of Geoffrey 
Morris’s keynote speech at UniForum 1990, The 
Open Decade . You may not care, but your mar¬ 
keting folks must. UniForum is now in the Trade 
Show 100 — the hundred largest trade shows (the 
largest is the biennial machine tools show) — and 
“open systems” got it there. Also included is an 
amusing and educational chapter of vignettes 
about large organizations that have moved to 
open systems, with their reasons and their ad¬ 
missions of what didn’t work. There are also five 
fine appendices: Data handling, User interface, 
Internationalization, Security, and System admin¬ 
istration , plus a glossary that’s a gold mine of 
buzzword definitions, and a list of contact ad¬ 
dresses and phones for key open systems orga¬ 
nizations. 

You know people who need this book, peo¬ 
ple who usually have to cull information like this 
from UNIX Today!, Datamation, or other com¬ 
panies’ marketing literature. So next week, when 
you’re grumbling about sales, marketing, or man¬ 
agement, stop complaining and do something. 
Give someone in the infrastructure a copy of Pam¬ 
ela Gray’s book. You’ve said, more than once, 
that your company’s problems aren’t a weak tech¬ 
nical staff, they’re key non-technical people who 
don’t understand important industry trends. Fix 
the problem. And before you give it away, read 
through it yourself. If nothing else, you’ll learn 
how an expert talks to the suits. 
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USENIX Board of Directors’ Meeting 


Below is a summary of the actions taken at 
the regular quarterly meeting of the usenix 
Board of directors held at the Opryland Hotel in 
Nashville, TN on June 9, 1991. 

Attendance: 

Rick Adams, Ed Gould, Rob Kolstad, Kirk 
McKusick, Sharon Murrel, Evi Nemeth, Michael 
O’Dell, Barry Shein, Deborah Scherrer, Ellie 
Young, Judy DesHarnais, Cynthia Deno, Daniel 
Klein, Eric Allman, Peter Collinson, Donnalyn 
Frey, Frances Brazier, Alan Nemeth 

Winter 9 92 Conference 

Tutorials: Klein felt it was a good model to 
cut down on the number of tutorials when lower 
attendance is expected at a conference. He and 
the staff had misgivings on the Board’s recom¬ 
mendation to offer more introductory tutorials, as 
these have had the poorest attendance histori¬ 
cally. Adams said that tutorials should be coor¬ 
dinated with the rest of the conference, our cur¬ 
rent 3 tracks don’t mesh, and we should consider 
more than one level of the conference. A lengthy 
discussion ensued regarding this topic. 

Future Conferences 

Winter Sites: DesHarnais said she was con¬ 
cerned that San Francisco and San Diego hotel 
rates would be higher. DesHarnais was instructed 
to investigate security issues at the Town & Coun¬ 
try Hotel in San Diego. 

Summer ’96 proposals: McKusick summa¬ 
rized the discussion: we are interested in pursuing 
Toronto, Atlanta, and Washington, D.C. as pos¬ 
sibilities for Summer of ’96. 

C++ Conference 

There was a discussion concerning the lower 
attendance. Young said she would pursue the 
ideas of changing the venue to a Fall date, and 
having demo sessions for the vendors. 

Nashville *91 Summer Conference 

Deno reported that there were 43 exhibitors, 
and she had kept costs substantially down. Her 
own sense for why companies cancelled is that 


exhibit budgets had been widely cut. Deno sug¬ 
gested that since the Board has decided to cancel 
the exhibition for the upcoming two summer con¬ 
ferences, it should consider other ways to get 
vendors to participate. 

DesHarnais reported that 1204 people had 
pre-registered. Scherrer went over her report and 
said she felt there was a lack of clarification on 
priorities and policies by the Board concerning 
program chair duties. She outlined her sugges¬ 
tions for future improvement, and Young will 
work with Allman on producing a set of guide¬ 
lines. McKusick on behalf of the Board thanked 
Scherrer for her efforts. 

Micro-kernel Workshop Proposal 

It was decided to accept Lori Grob’s proposal 
for a workshop on micro-kernels to be held in the 
USA in the next 12 months. 

Cooperative Efforts with Sun User Group 

Shein said that the idea behind the proposal 
from Salus is to increase joint activity and coop¬ 
erative projects between the groups. Gould said 
that we should look at extending a similar offer 
to other groups besides SUG. The Executive Di¬ 
rector was asked to arrange a fair and equitable 
exchange of the following services for our mem¬ 
bers with SUG and any other user group: 

• SUG and usenix members may register for 
each group’s conferences and workshops at 
the member rate. 

• usenix members will be allowed the mem¬ 
ber price for the SUG CD ROM. 

• Members of both usenix and SUG will 
qualify for any member discounts given on 
future products from either organization. 
SUG members may subscribe to Computing 
Systems at a discounted rate. 

Joint Symposium with EurOpen 

Brazier said that the proposed symposium on 
portability and interoperability would replace the 
regular EurOpen Spring ’92 conference. No funds 
would be required from usenix. EurOpen would 
handle the logistics, and usenix would assist with 
the program committee and publicity. 
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IR Report 

Collinson went over his report. He stressed 
that reports in ;login: are a main source of what 
is happening in the standards community for those 
outside, as well as for those inside, and that this 
is the major contribution usenix makes at this 
time. 

Review by Accounting Firm 

It was decided that a Review of the Associ¬ 
ation be conducted by an outside CPA. 

Executive Director’s Report 

Young went over her report and the follow¬ 
ing items were discussed: 

It was agreed the Evi Nemeth would be the 
official usenix representative to the EurOpen 
Fall conference. It was decided that an Annual 
Report to accompany the financial report to the 
membership should be co-authored by the Pres¬ 
ident and Executive Director. Job descriptions for 
the officers, Executive Director, and Board would 
be mailed to Young and the nominating commit¬ 
tee by Murrel. A regular strategic (and long- 
range) planning meeting would be held in the 
Spring and be timed to include the newly elected 
board members if in an election year. There was 
a discussion concerning candidates’ attendance at 
the Board meetings during an election year. Most 
felt that newly elected directors should attend the 
Spring and Summer meetings after the election. 


It was agreed that nominees should be invited to 
attend the Winter Board meeting in San Fran¬ 
cisco, but that we not pay for their travel and 
expenses to attend. Kolstad thought that more 
discussion is needed on having newly elected di¬ 
rectors at three meetings before they take office. 

;login: 

Young and Kolstad presented a proposal to 
improve the editorial content of ;login:. Kolstad 
suggested that it should be primarily a volunteer 
effort with guest editorial reviews and columns. 
Funds were allocated to be potentially spent on 
the new editor position for ;login: this fiscal year. 

Presentations at Conferences 

It was agreed that Kolstad and Shein will 
identify a volunteer member who wishes to take 
on the position of “Presentation Facilitator.” This 
position would be that of committee chairperson, 
and they will encourage the recruiting of a com¬ 
mittee, with Kolstad as board liaison. This chair¬ 
person will be presented with both the best pre¬ 
sentation concept and the presentation pre-review 
concept. The facilitator will be asked to use these 
and/or other methods to motivate our presenters 
to higher quality. 

Next Meeting 

It was decided that the next meeting of the 
Board will be held on October 12 and 13, 1991, 
in Berkeley, California. 
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Report on ISO/IEC JTC1/SC22/WG15 (POSIX) 

Meeting of 14th-17th May, 1991, Rotterdam, 

The Netherlands 

Dominic Dunlop—domo@natcorp. ox.ac. uk 

The Standard Answer Ltd. 


Rotterdam is the largest port in Europe. Per¬ 
haps that’s why everybody forgets it has an air¬ 
port. A nice little airport that you can get through 
in ten minutes — particularly if all the other par¬ 
ticipants in the posix meeting are flying into Am¬ 
sterdam airport and taking the train the rest of the 
way. But you can’t get a meal at Rotterdam air¬ 
port after 6pm: everything has its price. 

One of the prices of creating a standard is 
that you have to do things by the book. You have 
to know all the procedures, and to be able to 
demonstrate that you have followed them. Fall 
down in either respect, and, sooner or later, 
someone will notice and require you to put things 
right. The problem is that the only real way to find 
out about the procedures is to have been making 
standards for a few years, by which time you’ve 
made a few mistakes, inadvertently cut a few 
corners, and made a few assumptions which turn 
out to be wrong. 

Guess what. That’s just what the iso posix 
working group has done. 

As a result, the working group 1 came up with 
no fewer than 48 resolutions and 32 action items 
at its spring meeting. 2 In fact, there could have 
been even more resolutions, but some were voted 
down. Which raises another important aspect of 
standards-making: politics. I’ll deal with that as¬ 
pect last. For the moment, let me run you through 
the rest of the resolutions: 

Exit OSCRL 

You may recall from [1] that iso procedures 
had saddled the working group with a moribund 


1. That is, Subcommittee 22, Working Group 15, of 
Joint Technical Committee 1 of the International Or¬ 
ganization for Standardization and the International 
Electrotechnical Commission (iso/iec JTCI/SC22/ 
WG15), colloquially known as the iso posix working 
group, 

2. And I should know: I was taking the minutes. I 

should know by now never to volunteer. . . 


project, oscrl (Operating System Command and 
Report Language) which had its birth in the early 
eighties and the first flush of the movement to¬ 
wards osi. Despite intermittent attempts at re¬ 
suscitation, the corpse would not come back to 
life. We even called a meeting of past oscrl 
experts to write an epitaph (or, in iso-speak, draft 
a Technical Report) but nobody came. As a re¬ 
sult, oscrl lies buried in an almost unmarked 
grave: our first resolution simply says that there’s 
no more to be done, and gives fulsome praise to 
those who participated in the project. 

Let’s hope we hear no more of it. I think we 
killed it by the book. . . 

New Projects ‘R’ Us 

What we hadn’t done by the book was get 
official approval from Subcommittee 22, our par¬ 
ent body within iso, for all the posix work that 
we consider necessary. This goes beyond the basic 
operating system interface, the shell and tools, 
and administration, which we’ve had on our plate 
since the working group was formed. 

Without going into the detail of the differ¬ 
ences between the work that we thought had been 
approved, and that which the iso secretratiat 
thought had been approved, suffice it to say that, 
at its May meeting, the working group forwarded 
ten New Project proposals (nps) to SC22. If ap¬ 
proved, we will officially be able to work on: 

• Real time and real time extensions corre¬ 
sponding to draft IEEE standard 1003.4 and 
the revision following closely behind it. The 
French pointed out that both deal with 
‘soft’ real time, where one needs things 
done fast and reliably, but no planes fall 
from the sky 3 if an interrupt is serviced a 
few microseconds late. We may yet get in¬ 
volved with the ‘hard’ real time systems 
which address these needs. 

3. or fail to fall from the sky, I suppose. . . 
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• Transparent file access; that is, transparent 
access across a network to files on remote 
systems as defined by ieee 1003.8. 

• Protocol independent interfaces —sockets 
and/or Transport Level Interface. (Current 
work in the IEEE 1003.12 working group 
aims to unify the two approaches.) Remote 
procedure call is excluded so as not to con¬ 
flict with the work of SC21 4 on the topic. 

• Directory Service in line with the work of 
IEEE 1003.17. This work has to do both with 
access to X.500 directory services, and with 
the naming of posix objects with addresses 
which can be looked up using those 
services. 

• User portability extension— the extension to 
the ieee 1003.2 draft shell and tools stan¬ 
dard (is 9945-2 to be) dealing with the tools 
needed for program development: make, 
vi, and so on. 

• System interface extensions for the operat¬ 
ing system interface: advanced concepts 
such as symbolic links, taken from the 
forthcoming revision to the current 
standard 5 . 

• Shell and utility extensions from the revision 
to draft IEEE standard 1003.2. 

• Security changes to the existing 9945-1 
standard and the forthcoming 9945-2 shell 
and tools standard. These will be taken 
from IEEE 1003.6 and will update existing 
standards — hopefully in a way which does 
not break existing applications — in order 
to allow systems with enhanced security 
features to conform. 

Additionally, we have set the wheels in mo¬ 
tion for consideration of two further activities: 

• Conformance Test. We are suggesting that 
ieee Std 1003.3^ becomes an iso standard 
via the fast track procedure. Meanwhile, 
members of the Rapporteur group on Con¬ 
formance Testing are working on a ‘con¬ 
sensus specification for a single scaffold’ for 
testing. Perhaps they all want to hang to¬ 
gether . . . 


4. The folks responsible for osi. 

5. So as to conform with iso dogma, these will be 
appear first in Language Independent form, rather than 

as C language interfaces — see below. 


• The POSIX Guide otherwise known as 
1003.0, is being put forward by the working 
group as a proposed draft iso Technical 
Report. This has to do with Open System 
Environment Profiles, the subject of the 
group’s longest resolution, which consists 
mostly of questions that the group would 
like answered by those working on profiles 
elsewhere in iso. 

Add all those topics together, and you have 
a lot of work — a fact that has not been lost on 
those who think that the iso posix working group 
is getting too ambitious. But that’s politics, which 
I’m saving until the end. 

French Lessons for Ada™ 

In [3] I expounded at length on the issue of 
Language Independent Specifcations (Lis) — a 
topic which ISO has hitherto thought more im¬ 
portant than have those actually writing the bulk 
of the posix standards under the auspices of the 
ieee in the USA. Happily, early this year, the ieee 
came up with some money to sponsor the pro¬ 
duction of first full drafts of two documents: a 
Language Independent Specification defining ser¬ 
vices corresponding to those set out in the current 
operating system interface standard^ and a set of 
C language bindings to those services. Taken to¬ 
gether, these two documents should provide no 
advance over the existing standard — as far as C 
programmers are concerned. 

So why do it? Pour encourager les autres— 
such as the group in New Zealand which has 
expressed an interest in defining a Modula 2 bind¬ 
ing to posix services, and those developing a C++ 
standard 6 . We want them to do things in (what we 
consider to be) the right way, having learned 
useful lessons at the expense of the ieee’s 1003.5 
and 1003.9 working groups, which have been 
working on Ada and FORTRAN bindings to the 
posix operating system services defined by the 
1003.1 standard in terms of their interface to the 
C language. 

Inevitably, a definition in the C language 
presumes C-isms, such as a fairly permissive at- 


6. We have passed words of encouragement to the 
Modula 2 enthusiasts, but decided to keep quiet about 
C++ until ISO makes up its mind as to where it fits in 
the scheme of things. Politics again. 
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titude to type conversion and the possibility of 
function argument lists of variable length. Such 
idioms do not map onto good (or, indeed, legal) 
Ada or fortran, so the writers of those bindings 
standards have had to invent alternatives. As a 
result, the services, and the detailed semantics of 
those services, accessible from the Ada and for¬ 
tran differ from those available to programmers 
writing in C. At the iso level, people find it almost 
impossible to tolerate such inconsistency, even if 
the ieee has a rather more relaxed attitude. 

But the ieee also likes the standards that it 
develops to become international standards if 
they can. Last October, the iso posix working 
group said that it would not work on moving Ada 
and fortran bindings forward at the interna¬ 
tional level until they consisted only of a thin 
document describing the means by which the lan¬ 
guages bind to a language-independent service 
definition. The number of people in the world 
who are qualified (and motivated) to create such 
a definition can be counted on one’s fingers. None 
of them had an indulgent employer who would 
continue to pay them while they did work which 
would get the IEEE out of a hole and further the 
cause of international standardization, but which 
would produce no immediately measurable com¬ 
mercial benefit. 

So the ieee found the money, put the job out 
to competitive tender, and ultimately contracted 
with Hal Jespersen, long-time editor of various 
posix standards, to produce initial drafts. This he 
did on short order, and the documents are already 
being revised in the ieee 1003.1 working group, 
which intends to bring them to ballot early in 
1992. (^ describes what “bringing to ballot” 
means.) They have yet to be distributed at the iso 
level, the necessary level of polish not having 
been achieved, but should reach WG15 later this 
year. 

This means that, as far as iso is concerned, 
the standards production process is getting back 
on track after a period when it looked as if it was 
going to run into the sand because of disagree¬ 
ments on priorities between the U.S.-based stan¬ 
dards developers and the rest of the world. Sadly, 
the U.S.-based Ada community shows little sign 
of participating in this outbreak of cooperation: it 
is more concerned with getting a standard out of 
the door than in producing a standard which fits 
well into the ISO scheme of things. 


Fortuitously, the iso posix working group 
has discovered that there are other fish in the Ada 
sea 7 besides the ieee 1003.9 working group: a 
group of French experts has offered to make an 
early review of the draft posix lis standard, com¬ 
menting on its suitability as a basis for an Ada 
binding. The offer was gratefully accepted. 

Politics 

If U.S. Ada experts persist in ignoring ISO’s 
plans, we could end up with an international stan¬ 
dard for Ada bindings to posix services which 
differs considerably from the U.S. standard. This 
would be a Bad Thing, and would raise the level 
of exasperation of those working within iso at the 
performance of the U.S. as a developer of stan¬ 
dards on behalf of the international community. 

To date, there has been little cause for com¬ 
plaint with the progress of posix development by 
the ieee. Unfortunately, iso experienced consid¬ 
erable problems with two other SC22 projects for 
which the U.S. was the development agency: For¬ 
tran 90 and C 8 . This has made some national 
member bodies of iso unwilling to give the US 
responsibility for the production of further stan¬ 
dards (such as C++), and has given them cause 
to review existing projects where the us is the 
development agency, posix is one of these, so we 
have to be on our best behaviour. 

Then there’s history. Before the inception of 
the iso posix project, the Japanese proposed that 
a new Subcommittee, Systems Software Inter¬ 
faces (ssi), should be formed to handle it and 
other projects in what was unquestionably a grow¬ 
ing field. The Japanese expressed a willingness to 
provide a secretariat for (that is, to manage) the 
new subcommittee. Predictably, the U.S. didn’t 
like this idea, and prevailed with its view that, 
rather than delay standardization until a new sc 
could be set up, posix should be accommodated 
in the existing subcommittee handling computer 
languages — a subcommittee for which the U.S. 
happens to provide a secretariat. 

This spring, the Japanese, pointing to the 
increasing workload of the iso posix working 


7. Nuclear-powered submarines, perhaps? 

8. Scc^ 1 for gory details — and a plug for posix: ‘One 
Group That’s Working Well.’ 
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group, again argued in favour of a new sc. The 
group did not agree, and threw out a proposed 
resolution which would have welcomed a move of 
posix work to a new sc, should JTC1 decide in 
favour of creating one. Instead, we passed a res¬ 
olution which said that we like being in the lan¬ 
guages subcommittee, and will benefit from con¬ 
tinued close communication with other projects 
under that SC. 

The original resolution was overturned not so 
much because everybody thinks that everything 
about the current situation is wonderful, but be¬ 
cause the proposed new sc does not address a 
potentially even larger issue: that of profiles. Jim 
Isaak, convener of the iso posix working group 
and chair of the ieee Technical Committee on 
Operating Systems, wrote about profiles in [?1 . 
Profiles list the standards, parts of standards, or 
optional additions to standards to which systems 
must conform if they are to address the needs of 
particular applications areas. They are nearly es¬ 
sential if one wants to make sense of the dozens 
of OSI standards. It seems that posix is moving in 
the same direction, particularly since posix con¬ 
forming systems will need also to conform to 
other standards such as those for SQL and OSI. 

A meeting prior to the main assembly in 
Rotterdam drafted a framework for future work 
on posix profiles and, equally importantly, for 
cooperation among the many bodies which are 
developing them. But there’s still much work to 
do. I expect we’ll discuss the topic again at our 


next meeting in Stockholm, Sweden, in early No¬ 
vember: the issue won’t go away. Nor will the 
matter of the new sc, even if some of us might 
want it to. I’ll keep you posted. 
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Report on the July IEEE POSIX Meeting for EurOpen 

Stephen R . Walli <stephe%speaker@mks.com> 

Temporary EurOpen Institutional Representative 


POSIX is a family of standards which has 
grown in a hodge-podge fashion since its formal 
IEEE birth in 1985. It started small with a specific 
goal in mind, and it can be argued that the need 
is answered by the posix. l standard otherwise 
known as iso/iec 9945-1. Somewhere along the 
way, the process grew dramatically. An explosion 
of projects under the banner of posix has created 
a huge complex entity which everyone expects to 
fulfill their own diverse needs. 

Until the recent past managing this complex¬ 
ity has been pretty informal, using seat-of-the- 
pants discussions. Long-talked-about committees 
are being created and are gaining momentum. 
The management process is being put in place to 
hopefully coordinate this huge volunteer effort of 
building an industry standard for something as 
complex as a full function operating system. (By 
management, I refer to the process coordination 
type, not the suit-and-tie type.) 

IEEE posix meetings now have two very dif¬ 
ferent faces. There is the working group face. 
Each individual working group has a chair ded¬ 
icated to the task of preparing a specific draft 
document to be balloted for eventual acceptance 
as a standard. Knowledgeable volunteers work in 
these rooms discussing, editing and arguing the 
issues for their particular corner of posix. 

Then there’s the coordination face. Here, 
also, we are beginning to see an explosion of 
committees. There are now steering committees 
dedicated to: 

• Conformance Testing issues across all 
projects, 

• Distributed Services issues across the sev¬ 
eral working groups involved with network 
oriented interfaces, 

• Windowing User Interfaces issues, 

• Profiling issues within posix, and their re¬ 
lationship to profiles at large. 

The Project Management Committee (pmc) 
is a subcommittee of the Sponsor Executive Com¬ 
mittee (sec). The sec is the guiding force behind 


the IEEE’s Technical Committee on Operating 
Systems Standards Subcommittee (tcos-ss) . 
tcos-ss is responsible for Operating Systems stan¬ 
dards. The pmc reviews new project requests 
(pars) and checks on the status of current working 
group projects. 

A new Ad Hoc Committee began meeting in 
Santa Clara to discuss the fundamental issues of 
“a POSIX architecture.” What does this “thing” 
look like? Will the Security extensions to iso/iec 
9945-1:1990 (posix. l) work together with the 
Real-Time extensions? What happens when the 
Transparent File Access extensions are added to 
the picture? 

Here we cover the recent ieee posix working 
group meeting from the coordination point of 
view, tracking events across the projects instead 
of covering the individual projects from within. 

The Project Management Committee 

July’s meeting was the second set of working 
meetings of the pmc. This group is still getting 
used to its role as a project reviewer and scruti- 
nizer of new project authorization requests (par), 
pars are created for each draft document in the 
process. Once a par has been passed by the pmc, 
and accepted for sponsorship by the TCOS-SS sec, 
it arrives at the IEEE’s Standards Advisory Board 
for final and formal acceptance as a work item for 
a working group. 

The pmc suffered the same malaise the rest 
of posix projects suffer at times. People were 
extraordinarily busy with their “real employ¬ 
ment” between the April and July meetings. 
Many of the reviews of existing projects which 
were scheduled for this meeting weren’t done. 

The mentor for posix.0 (POSIX Guide) 
completed her review of the project, posix. o has 
become real. It began initially as a working group 
of people with a higher level of concern for posix. 
It was the group holding discussions about how 
posix would be used in a more global sense, 
rather than minute examination of the nitty-gritty 
individual function calls or language bindings. 
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posix.o isn’t building a document for standard¬ 
ization, but rather an overall guide to Open Sys¬ 
tems Environments. It was through this group’s 
efforts that the Profiles Steering Committee was 
born. 

The posix.o document is now being strongly 
lobbied for acceptance as an iso Technical Re¬ 
port. Many issues which have been left to rest for 
quite some time now are all rearing up again. 

It was assumed when the group was formed 
that the other working groups would automati¬ 
cally provide the liaison people to ensure that the 
models in the Guide were accurate. This did not 
happen. The PMC reported on this lack of in¬ 
volvement and took steps to get the SEC to ensure 
that there is adequate review of the Guide by 
other working groups. The participation of work¬ 
ing groups was also demanded in the discussion 
about architecture framework. This will hopefully 
see action at the next ieee posix meeting in Oc¬ 
tober. 

The one new PAR reviewed by the PMC at this 
meeting was the request from POSIX. 5 (Ada Bind¬ 
ings) for a project to address posix real-time ex¬ 
tensions. This work passed the pmc with some 
minor word-smithing, and is discussed later. 

Language Independence Specifications 

Programming language independent specifi¬ 
cations (lis) are a requirement placed on the ieee 
posix working groups by iso. The current and 
future c-based functional interfaces will eventu¬ 
ally be described semantically in an lis and with 
various different programming language bindings 
associated with each. 

A language independent specification of 
posix. l and its C binding (posix. 16 ) now exist. 
These documents will shortly go out for mock 
ballot. A mock ballot is useful for finding re¬ 
maining problems with a document prior to being 
sent for real ballot. For comparison reasons 
posix.i/lis, posix. 16, and the ANSI C standard 
should be equivalent to the existing iso 9945-1 
standard. 

The ballot period will hopefully be 45 days, 
starting in early August. The mock ballot will be 
sent to the posix. 1, posix.5, and posix.9 mailing 
lists, but it is an open ballot. 

It was suggested that the tcos-ss Program¬ 


ming Language Independent Specification Guide¬ 
lines should also be added to the ballot since 
readers may find something they consider incor¬ 
rect, and it is pervasive in the documents because 
it is due to a particular method or guideline from 
the Methods document. 

General ballot instructions include: 

• determining the equivalence of the new lis 
and C Binding to the existing 9945-1 (re¬ 
member, 9945-1 cannot be broken); 

• determining if the LIS and C Binding clearly 
relate; 

• determining whether the split of material 
between the lis and c Binding is a coherent 
one, and 

• determining how easy it is to produce an¬ 
other language binding to the the lis. 

There are still many questions to be answered 
with the lis work. Conformance specifications for 
the lis and the nature of test methods are much 
talked-about issues. The validity of the current 
object model for LIS and the lack of an event 
model are problems to be addressed. Interoper¬ 
ability is still not addressed formally. Hopefully, 
the mock ballot will contribute to all of these 
areas. 

The other posix language bindings, Ada 
(posix.5) and FORTRAN-77 (posix. 9 ), are still 
proceeding with their ballot resolution process. 
iso/iec JTC1/SC22/WG15 has accepted the posix.5 
and POSIX. 9 position of finishing their current 
ballot and producing language bindings to future 
lis in the revised iso languages once all of those 
documents exist and are stable. Current drafts 
were circulated at the May WGI5 meeting for 
review and comment. New Zealand has proposed 
building a Modula-2 binding to POSIX. 1 as a work 
item to iso. 

Within the posix working groups there is a 
new wrinkle with the lis work, posix. l2 (Protocol 
Independent Interfaces) is proposing to do two 
bindings to an as yet undefined LIS: one for BSD 
sockets, and one for X/Open’s Transport Inter¬ 
face (xti) . Two language bindings to the same lis 
isn’t unusual. They just happen to be in the same 
language! A lot of this has to do with two estab¬ 
lished bodies of experience unable to compro¬ 
mise, and attempting to arrive at a creative so¬ 
lution. 
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I don’t believe that they’ve really thought it 
through. Harmonizing the functionality in the two 
existing C bindings to an independent specifica¬ 
tion will be non-trivial and possibly infeasible. If 
the functionality is completely covered by the Lis 
and the two bindings wholly overlap, why are they 
not harmonizing the interfaces? 

Another twist is the interoperability question 
between two language bindings. People often use 
the example that one program running in one 
process context written in one language which 
writes a pipe, should be understood by a different 
program in a different process context written in 
a different language reading the pipe. I don’t 
think the intent here is that a program using sock¬ 
ets will communicate directly to a program written 
to use XTI. 

Profiles Steering Committee 

July was the first working meeting of the 
Profiles Steering Committee (psc). The fledgling 
group is attempting to wrestle with a gargantuan 
task. They seem torn between trying to sort out 
the possibly limited and thorny problems of posix 
profiles, versus helping to solve the world’s pro¬ 
filing and framework problems. That is a some¬ 
what naive statement, based on my narrow view 
of what a profile could be, and should under¬ 
standably be taken liberally salted. 

The first meeting became somewhat mired in 
liaison issues with the rest of the world. They were 
fortunately able to pull out of this mode and 
formed two small working groups to address two 
specific problems. 

One small group dealt with the harmoniza¬ 
tion of terminology across various different 
groups working both inside and outside of posix. 
The second group dealt with formulating the rules 
by which posix profiles are built. Both of these 
groups made good progress during the rest of the 
week. 

Ada Real-time Study Group 

The POSIX Ada working group (posix. 5) 
wants to begin building a binding to the POSIX. 4 
Real-time Extensions. They received permission 
to start a study group at the April meeting, and 
had a project request formally approved at this 
meeting. The new project, christened posix. 5A 


(Ada Binding to posix. 4), is under the direction 
of the current posix .5 working group. 

The group is not extending the Ada language 
for real-time capabilities. They are binding to the 
currently defined posix .4 interface definitions. 
The “thick” binding versus “thin” binding issue 
has been put off. A language independent spec¬ 
ification of posix .4 does not yet exist. The group 
will continue in their current process of building 
usable documents for programmers. 

The group recognizes that there is a co¬ 
ordination issue with iso for both SC22/WG9 
(Ada) and for the current proposed work item for 
Real Time Ada Extensions (iso/lEC jtci N 1266, 
dated 1991-02-22). This is the extra (Exten¬ 
sions Temps R6e\ a Ada ...) work from AFNOR, 
the French member body of iso. As yet, iso has 
not assigned sponsorship for this work item. 

GUI Wars Revisited 

We're baaaack . - . 

For the second meeting running, discussion 
was dominated by the two opposing direct ballot 
project requests for an Open Toolkit Environ¬ 
ment (Open Look) and a Modular Toolkit En¬ 
vironment (OSF/Motif). These projects had been 
rejected “at this time” at the April meeting in 
Chicago. A letter from Paul Borrill (vice- 
president for standards in the ieee Computer So¬ 
ciety, and a member of the ieee Standards Board) 
forced the re-opening of the issue. The letter was 
seeking reasons for rejection and stated that two 
standards in the same project space was not suf¬ 
ficient reason to reject the requests. 

A subcommittee was formed early in the 
week to summarize all of the discussions that took 
place at the April meeting. After many meetings 
and much writing, the subcommittee delivered its 
report at Thursday evening’s sec meeting. 

The sec members were asked if they agreed 
with any of the statements (pro and con) con¬ 
tained in the subcommittee’s report. The majority 
of the statements were against acceptance of the 
pars. Many SEC members had many problems 
with accepting the two pars. This is how the 
motion to sponsor both pars failed. A quick straw 
poll demonstrated that many people felt there was 
a fundamental problem with the projects. These 
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problems would not go away with some rewording 
or reorganization of the par. 

It was readily acknowledged that the docu¬ 
ments could not move forward as direct ballot 
documents. This was a fast track option to be used 
with non-controversial documents, clearly not the 
case here. This should have been used in April as 
the stopping point! A real vote was then taken 
and the motion to sponsor the projects failed. 

People barely caught their breath when a 
motion to remove sponsorship from P1201 was 
made. (You could have heard a pin drop....) The 
rationale is that P1201 was supposed to be de¬ 
veloping a standardized toolkit for windowing and 
clearly suffers from the same fundamental flaws as 
the two defeated project requests. 

P1201 has been moving ahead for several 
meetings, working to an unrecognized project 
scope. The working group has been attempting to 
come up with a “virtual” toolkit for windowing, 
under which Motif or Open Look could be 
plugged. Indeed, they claim anything could be 
plugged into the new model, including a Macin¬ 
tosh or Presentation Manager interface. 

They have made substantial progress the past 
two meetings working with the xvt specification 
as a base document, probably because former 
supporters of Motif and Open Look have been 
busy with their own project requests. Now they 
face complete termination. This removal of spon¬ 
sorship affects P1201.2 (Recommended Drivabil- 
ity Practise) as well. 

The motion to remove the P1201 sponsorship 
has been tabled until the October meetings. The 
Project Management Committee was due to re¬ 
view this project for the October meeting anyway, 
so it was felt they should be allowed to do their 
job first. What this really means is that yet an¬ 
other meeting is going to be turned on end with 
discussions of standardization of windowing in¬ 
terfaces. 


Institutional Representative Voting Issues 

A subcommittee of the Sponsor Executive 
Committee (sec) recently balloted the tcos Op¬ 
erating Procedures. In general there is nothing 
too controversial in them, with one notable ex¬ 
ception. The vote is being removed from tcos sec 
Institutional Representatives (ir). It is an issue 
that is sensitive enough to be called out in a 
mini-ballot all by itself. 

The mini-ballot phrasing was slanted towards 
removing the vote, and has already been attacked 
on the net. Apparently history is the culprit here. 
It’s always easy to blame history. It’s never there 
to defend itself. 

The concept of IR was created within the ieee 
standards arena with the intent of allowing other 
accredited standards organizations to have rep¬ 
resentation. tcos extended the ir role to include 
X/Open, usenix and Uniforum. It looks good to 
be able to point to the greater acceptance of a 
standard by the technical community this way. 

Other groups applied for this status. There 
was a small proliferation of irs within the sec. A 
concern was raised over the growing numbers of 
“outside” votes being generated. With no good 
definition in the ieee standards hierarchy as to 
what exactly an IR is, there’s no way to limit the 
number. 

The results of the mini-ballot will be inter¬ 
esting. I personally objected on my ballot, arguing 
that irs have a voting role and that the rules 
should be modified to adequately define irs. All 
of the irs can be reviewed in the light of the new 
definition. There are already rules in place to 
remove irs. irs often have a broader picture of 
POSix than individual working group chairs, intent 
on their own working group progress and prob¬ 
lems, and therefore add to the process. 
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Letter to the Editor 


The following letter was received by the As¬ 
sociation with the request that it be printed in its 
entirety. -EY. 

usenix President Kirk McKusick has pub¬ 
lished an article in ;login: about my involvement 
with usenix standards activities. He did this 
against my strenuous objections. I have known 
Kirk pretty well for a while, and I’m sure he did 
this with all good intentions, but the article leaves 
out a lot of information and may thus mislead the 
reader. 

First of all, Kirk’s article does not make it 
clear that my efforts related to standards on be¬ 
half of usenix were not to promote standards, 
rather to try to keep them from interfering with 
innovation, by providing appropriate technical in¬ 
put, by lobbying against problematical features, 
and by getting those involved who could make a 
difference. 

The mention of only me in Kirk’s article gives 
the impression that I was solely responsible for 
USENIX standards activities. This is not true, and 
is extremely unfortunate, since it perpetuates a 
myth that has contributed to the lack of serious 
consideration the usenix board has given to stan¬ 
dards activities. It also omits mention of many 
who deserve thanks. 

The snitch report idea was invented by 
Grover Righter, who had previously been active 
on a usenix Standards Policy Committee. He 
made the suggestion in response to my expressed 
intention to retire as USENIX IR due to overwork, 
and my concerns that the job had simply grown 
too big (already, in 1988) for one person, or even 
for the small committee he was part of. By getting 
people already active in the various committees to 
report on them, the membership and others (in¬ 
cluding the other committees) could be informed, 
and the IR could have some idea of when action 
would be appropriate. 

The snitch organization survived at first 
largely because of Shane McCarron’s activities as 
the first snitch editor, and later because of those 
of Jeff Haemer. Others were also active in orga¬ 
nizing the snitch activities, including Mark 
Tietelbaum and Susanne (Smith) Wilhelm. The 


support of Kirk McKusick, and occasionally oth¬ 
ers, on the board of directors was invaluable, as 
was that of the executive directors, Peter Salus 
and then Ellie Young. Most especially, the snitch 
reports survived because the snitches were willing 
to write reports for nothing but a free dinner and 
vague indications that they were doing a good 
thing in getting snitch information distributed 
widely. 

The 1987 POSIX workshop Kirk mentioned 
could not have succeeded without the assistance 
of the conference coordinator, Judy DesHarnais, 
the executive director, Peter Salus, and especially 
of Debbie Scherrer and others at mt Xinu. 

The White Paper on System Administration 
Kirk attributed solely to me was actually coordi¬ 
nated by Susanne (Smith) Wilhelm, whose name 
appears first on it for that reason. That White 
Paper is generally regarded by standards partic¬ 
ipants familiar with it as having been instrumental 
in changing the focus of the IEEE 1003.7 System 
Administration committee from a single machine 
model to a distributed model. 

The speculations about my motivations are 
inappropriate and sometimes inaccurate. It was 
never my intention to spread the influence of the 
usenix IR beyond the U.S. usenix had always 
had influence overseas, simply because overseas 
user groups had not yet seen fit to take a direct 
hand in standardization. When the IEEE TCOS 
(POSIX) process moved in to the international 
(ISO/IEC JTC1 SC22 WG15) arena, international 
interest nonetheless increased, increasing the bur¬ 
den on usenix, at a time when it had already 
become necessary to seek funding for the usenix 
IR position just to manage what was needed for 
usenix. My motivation was to get other user 
groups involved in standardization activities in 
order to reduce the burden on usenix. Also, I was 
under the impression that usenix was as much a 
Canadian technical user group as a U.S. one. 

The actual eventual agreement with EUUG 
(now EurOpen) to fund the ISO Monitor Project 
would not have been possible without the efforts 
of Michel Gien, Johann Helsingius, Dominic 
Dunlop, and Kirk McKusick, and the assistance 
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of others such as Sharon Murrell and Alan 
Nemeth. 

A more important effort to move the snitch 
reports into a structure with broad support from 
a range of international user groups was not ap¬ 
proved by the usenix board at their January 1990 
meeting. 

Another POSIX workshop that would have 
involved several other user groups and even a 
standards-making organization was not held be¬ 
cause of lack of cooperation from the usenix 
board. 

What effectiveness usenix had in the pro¬ 
cesses of TCOS and of the U.S. Technical Ad¬ 
visory Group (TAG) to WG15 would not have 
been possible without coordination and cooper¬ 
ation with others, such as the TCOS officers, 
particularly Jim Isaak, Donn Terry, Hal Jes- 
persen, and Maggie Lee. The other institutional 
representatives were particularly important, es¬ 
pecially Heinz Lycklama, who originally proposed 
that usenix have an Institutional Representative 
(it was Wally Wedel who found one), Ralph 
Barker, Shane McCarron, Martin Kirk, and Fritz 
Schulz. Other standards participants too numer¬ 
ous to mention were of great assistance. 

Actual usenix ballots on TCOS standards 
documents, none of which were ever directly 
funded by usenix, owe their existence to those 
who provided input to them, including Martha 
Nalebuff, Keith Bostic, Mike Karels, Kirk McK- 
usick, Shane McCarron, Robert Elz, Mark Olson, 
Guy Harris, and many others. 

By 1989 it had become clear that, even with 
the snitch organization, the usenix IR position 
could not be handled by a volunteer. Nonetheless, 
it was important for usenix to continue to par¬ 
ticipate in standards activities, because very few 
others represented users instead of vendors, be¬ 
cause of its sponsorship of one of the few Insti¬ 
tutional Representatives (whose votes are in sev¬ 
eral senses more visible than ordinary ballots), 
and because of its ability to stand apart from 
specific commercial interests. 

A proposal from me for a usenix Standards 
Manager position, including support for an IR 
and the snitch reports, was approved by the us¬ 
enix board in January 1990, but at an arbitrarily 


lower level of funding than proposed, with no 
specific reasons given by the board for the funding 
reduction. Kirk’s article might be read as implying 
that I retired as usenix IR when that funding ran 
out. This was not the case. A proposal from me 
for further funding was turned down in September 
1990. The posted summary minutes of that board 
meeting say only that “Quarterman’s approach 
will not work.” 

I was personally relieved to be rid of the 
burden. However, the board unfortunately did 
not separate my participation from the usenix 
standards activities themselves. Nor did they un¬ 
derstand the relation of the snitch reports to the 
rest of the standards activities, as indicated by 
their approval of an unrealistically low level of 
funding soley for the snitch reports, with no fund¬ 
ing for the lobbying on their behalf traditionally 
done by the IR, nor for any proposal, lobbying, 
or balloting action to be taken in response to 
them. 

Because I thought usenix standards activi¬ 
ties were more important than my personal in¬ 
volvement, I chose to continue to assist in trying 
to get some sort of useful participation funded by 
the usenix board. A proposal for a usenix IR 
was written by someone else, with input from 
others (named in the proposal) who were willing 
to assist. Those involved spent more than a hun¬ 
dred hours on it, plus more on the related pro¬ 
posal about broad international support for the 
snitch reports. The IR proposal was nominally 
approved by the usenix board in January 1991, 
but without appointing anyone to fill the position 
it proposed. 

However, the qualifications for an IR set out 
in that proposal were not followed by a search 
committee appointed by the usenix board. Sev¬ 
eral qualified candidates were either not consid¬ 
ered or not completely interviewed. A candidate 
was chosen who had no experience in TCOS stan¬ 
dards activities one who asked several people who 
had not been considered as candidates, before 
they were notified by usenix of the decision, to 
tell him what to do. 

I fear that Kirk’s article, in juxtaposition with 
the announcement of the board’s appointment of 
someone to represent USENIX in standards activ¬ 
ities, will lead to the impression that I approved 
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of that appointment. So I feel I must speak up. 
I did not approve of that appointment, nor es¬ 
pecially with the manner in which it was done. 

I consider the actions of the usenix board of 
directors in this matter to have been very irre¬ 
sponsible, not only to the organization they are 
supposed to represent, but to the broader industry 
and community. Their actions also show a com¬ 
plete lack of understanding, if not outright con¬ 
tempt, for the large amount of volunteer effort 
that went into the proposal and into support of 
previous standards activities, usenix needs con¬ 
sistent and serious support for a meaningful and 


Errata 


In the July/August issue the Report from the 
Nashville Conference contained a writeup on the 
“Most Egregious Misuse of UNIX Utilities Con¬ 
test”. We apologize for the misprint of Larry 
Wall’s entry included in that article. Here is the 
correct versions. 

Task: modulus operator program 

Implementation: use line wrapping and di¬ 
version in nroff 


rational technical voice in the standards process, 
without which innovation will be stifled. I hope 
that the usenix membership will take these ac¬ 
tions of their board into account at the next elec¬ 
tion of directors, or perhaps before. 

Perhaps this letter, unlike at least two snitch 
reports, will be published in ;login: without cen¬ 
sorship or unauthorized editing. Please direct any 
questions about usenix Standards decisions to 
those responsible for making them. 

Sincerely, 

John S. Quarterman 


#l/bin/sh 

nroff < < EOF I wc -w 

*ai xx 

'll $2 

'll +$2 

'echo "ID * $1 I be I tr-ai I sea 's/D/D /g' ' 

'ai 

EOF 

(You invoke it with two numeric arguments. 
For examples, if you say “modulus 23 10”, it 
prints out 3.) 
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Report from EurOpen 

Alain Williams< addw@phcomp.co.uk> 
Troms0 Conference 

Our Spring conference was held in Troms0, 
Norway. This is a location north of the Arctic 
Circle and so it was cold, but provided a splendid 
view of the midnight sun — weather permitting! 

In addition to the tutorials and technical ses¬ 
sions, a conference provides an opportunity for 
the EurOpen Governing board to meet. Two im¬ 
portant decisions were made: to accept applica¬ 
tions for membership from Algeria and Tunisia. 
This brought us up to 22 National Groups in all. 
The main difference between EurOpen and us- 
ENix is that EurOpen is a federation of national 
groups. 

Dieter Glauss writes about the first day’s 
technical talks: 

The technical sessions took place in the Kul- 
turheset. Three hundred and thirty-five delegates 
found their way to Tromsp. The first lecturer was 
Michael D. Schroeder. He delivered a very good 
overview on what distributed systems are and 
what they have to be. First he took a look at the 
good old days of timesharing with no naming 
problem (uniform names for users, files, func¬ 
tions, etc.), only one management domain, co¬ 
herent file sharing, simple, reliable mail systems 
and uniform authentication. He pointed out that 
the new distributed systems also have some good 
points — information and resource sharing in 
wide geographical and organisational spread, use 
of cost-effective work stations, growth in small 
increments and large range of size and autonomy 
from decisions, vendors, software versions, and 
crashes (not all crashes at one time). The ideal 
distributed system may be a system which meets 
the requirements from both centralised and de¬ 
centralised systems. Schroeder argued that inter¬ 
faces are the key to open systems. Each service 
must be defined by an interface (meaning by a 
contract). In the second part of his talk he focused 
on naming, security, and availability issues. We 
need systems for fault recovery in less than a 
second. This lecture was a very good introduction 
into the field of distributed systems. 


With Shape Muellender’s look to the good 
and bad things about Amoeba, the presentation 
of the mainstream in operating systems started. 
He listed things he would have done differently, 
if he had to do it all over again. Michel Gien 
presented some aspects of Chorus, distributed 
and UNIX compatible. Simon Patience gave an 
even more commercial lecture about OSF/1. Dave 
Presotto presented Plan 9 with a two hour talk in 
40 minutes. Though he did it in a very fast man¬ 
ner, people were quite happy with the presenta¬ 
tion. The basic idea is to have only files to man¬ 
age. The way these new systems work are very 
interesting. My favourite is Plan 9, because it 
based on such a simple idea and it looks very easy. 
Also OSF/1 with its MACH Kernel is a fine thing 
and as a look at the exhibition showed, this seems 
to be the way industry is moving. 

After the coffee break, Andrew Schuelke 
tried to explain some efforts of UNIX interna¬ 
tional, but I didn’t see the goal. A forum closed 
the technical sessions on the first day. All speak¬ 
ers of the day chaired by Micheal D. Schroeder 
discussed some questions concerning security real 
time support and standards. A debate between 
OSF and UNIX International was attempted, but 
these two major organisations surprisingly agreed 
with each other. The audience was very enthu¬ 
siastic. I think a typical discussion was: “We need 
standards but we don't want to accept a standard 
defined by anyone else." Sape Muellender sug¬ 
gested that if using a standard, that only one 
standard be used. Dave Presotto saw the main 
problem of standards as a loss of performance 
because of a lot of layers. 

This evening the first social event was sched¬ 
uled, a trip on a ferry through the fjord with free 
shrimps and beer. Although the weather wasn’t 
good (we had rain and snow,) we were in a tre¬ 
mendous mood. 

The competition from HP (with a calculator 
as a first prize) was one challenge on the ferry. 
The question was: “How many MIPS has the 
University of Troms0 bought from Hewlett Pack¬ 
ard?" The suggestions ranged from not enough, to 
1 and 27,000 MIPS. Some of these very good 
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answers were rewarded with some wine, and the 
first prize went to Mary Bitar of Boston. 

The sessions on the next two days started 
with talks on how parallel systems are changing 
the way applications are written. It continued with 
talks on architecture, scheduling and manage¬ 
ment, moving to programming languages and dis¬ 
tributed/client-server solutions on Friday. 

Budapest Conference 

By the time that you read this EurOpen will 
have had its Autumn conference in Budapest, 
Hungary. It followed the traditional format of two 
days of tutorials followed by three of technical 
papers and discussions. I will give you a report on 
this in the next issue. 

Future conferences 

Our next conference (13-17 April, 1992) will 
be in Jersey, one of the British Channel Islands. 
It will be co-sponsored with usenix. I know of 
several members who are planning to arrive there 
by yacht, and I wish them calm seas! 

The Autumn conference next year (25-29 
November) will he held in Amsterdam, The Neth¬ 
erlands. It will be held in conjunction with Uni- 
Forum. The idea is to draw on the strengths of 
both organisations to create a truly European 
conference in conjunction with a major exhibi¬ 
tion. By working together on some projects 
EurOpen hopes to further one of its objectives: 
to promote and advance the knowledge, use, and 
application of open computer systems. 

For further information on EurOpen events 
and proceedings please contact: 

EurOpen 
Owles Hall 
Buntingford 
Herts SG9 9PL 
England 

Tel: + 44 763 73039 
Fax: +44 763 73255 
Net: europen@EU.net 


Call for Tutorial Proposals 

A message from Neil Todd: 

The tutorial programme is one of the major 
elements of a EurOpen conference. In recent 
years, classes on a wide range of subjects have 
been taught by recognised authorities in their 
field. Past classes have included System V and 
Berkeley kernel internals, System Administra¬ 
tion, UNIX networking, X Windows concepts, and 
UNIX standards to name just a few. 

It has been policy to extend the range and 
variety of tutorials offered. In order to do this new 
tutorials are constantly required. 

EurOpen is now seeking proposals for classes 
for our 1992 conferences to be held in Jersey 
(April) and Utrecht (November). Proposals from 
tutors are invited on any topic, although past 
experience has shown that advanced tutorials are 
better attended by delegates than introductory 
ones. 

All EurOpen tutorials are taught in English 
and usually last a full day, although half day 
classes are accepted from time to time. A full day 
class will normally be supported by between 
80-200 slides, together with up to 200 pages of 
additional material. Previous experience has 
shown that classes can be successfully taught by 
either one or two tutors. 

As well as seeking new tutors, we are also 
seeking new tutorial subjects, but remember the 
subject must not be so specialised that only a very 
small number of experts would have an interest in 
it. Please submit your ideas for topics. 

Please send your proposals and suggestions 
to the address below. I will also be pleased to 
discuss possible proposals with you. 

Neil Todd 

EurOpen Tutorials Officer 
Owles Hall 
Buntingford 
Herts SG9 9PL 
UK . 

Email: neil@pio.gid.co.uk 
Fax: +44 763 73255 
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Ninth Annual 

Conference 
& Exhibit 

December 9-11,1991 
San Jose Convention Center 
San Jose, California 


For the past eight years, the Sun User Group (SUG) has produced 
THE Sun user event of the year. The conference provides the 
opportunity for engineers, scientists, third-party vendors, 
end-users, developers, executives, and others to listen, share 
experiences, and learn how to better deal with both hardware 
and software decisions facing Sun and SPARC 0 users today. 

The theme for this year's conference is, "Distributed Applications 
and Multiprocessor Technology" and will feature... 

.. .Nearly 100 sessions and panels. In addition to presentations 
centering on the theme of the conference, also featured will 
be talks in the following five categories: Instructional, System 
Administration, Performance Analysis, Scientific Computing, 
and Commercial Applications. 

.. .Tutorials will run all day Sunday, December 8. There will be 
eight tutorials which will run concurrently. Tutorial topics are: 


► Writing Distributed Applications Using the ONC Platform 

► Micro-Kernel Technology 

► Basic X Concepts 

► Introduction to the Domain Name System 

► UNIX Administration for VMS System Managers; 
or, VMS + UNIX = Oil + Water? 

► X and the Administrator 

► Topics in UNIX Security 

.. .Over 200 exhibits housed in a 100,000 sq. ft. convention 
center will make this year's exhibit ihe largest in our history, 
doubling the size of last year's show. See the latest Catalyst and 
third-party vendor producls ported to Sun. Also included will be 
vendors from the SPARC® community. 


For registration or exhibit information please contact: 


SUN USER GROUP CONFERENCE OFFICE 


201 Son Antonio Circle, Suite D265 


Mountain View, CA 94040 


415/948-0998 • Fax 415/948-6802 
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An Update on UNIX-Related Standards Activities 

Stephen R. Walli 

Report Editor, USENIX Standards Watchdog Committee 


The Five Great Myths of Open Systems 
Standards 

I recently read a column where the author 
described computer people at cocktail parties as 
the doctors of the 90’s. Instead of everyone want¬ 
ing to discuss their aches and pains with some 
poor medical practitioner while they’re trying to 
sip scotch and nibble hors d’oeuvres, computer 
people are plagued with the latest chat from com¬ 
puter literate business people. 

No longer are you merely cornered by DOS 
know-it-alls, now you get to deal with the sweep¬ 
ing issues of GUI Wars, and whether UNIX will 
displace DOS on the desktop. Open systems are 
in vogue. Standards are “sexy”. 

With all of this comes the new “Open Sys¬ 
tems” know-it-all. These are people who can spell 
posix, but can’t pronounce it. They’ve all been 
taken to lunch recently by their favorite market¬ 
ing rep from one of those lavish companies whose 
name is a regulation three letter acronym, let’s 
call them TLA for short. 

I started discerning certain patterns in all of 
this idle gossip and chatter, and now present to 
you the Five Great Myths of Open Systems Stan¬ 
dards: 

Myth #1 

“Vendor TLA IS the standard.” This is the 
traditional mix-up between de jure standards, and 
de facto standards. Or REAL standards and mar¬ 
ket share. De jure standards are built by accred¬ 
ited standards development bodies. There is a fair 
process involved to ensure that all points of view 
are heard. It is a consensus process, not a majority 
one. 

De facto standards are mostly under the lim¬ 
ited control of a single organization. They are 
often trademarked. If they are available at all 
outside of their controlling organization, the tech¬ 
nology is often licensed. The holder of the license 
effectively controls where they want to take the 


technology. They accept input from some form of 
user constituency, but ultimately they run the 
show. I look at this as the difference between a 
POSIX standard interface, and a UNIX operating 
system. 

Myth #2 

“Vendor TLA is part of the standards de¬ 
velopment group, and they’re donating this tech¬ 
nology to the standard.” Always a knee slapper. 
As if all it took to make a standard was for a 
vendor to donate part of its technology, obviously 
out of the goodness of its heart for mankind. 
These people have not participated in the excite¬ 
ment of Threads Wars, or the current painful GUI 
Wars. 

Many vendors would love to have their spec¬ 
ification as a standard. It gives them an instant 
product to sell into the hot “standards” market. 
They just have to get past the rest of the standards 
working group, made up of various backgrounds 
and biases. 

Then comes a balloting group, a superset of 
the working group. These people haven’t neces¬ 
sarily had the benefit of participating in the dis¬ 
cussions that led to a decision. The popularity of 
publishing the rationale for decisions helps alle¬ 
viate this problem, but not always. There will 
always be people in a balloting group that know 
their solution is the technically correct one. It’s 
much easier to disagree with the committee, bal¬ 
loting a draft you didn’t help make, than in the 
working group sessions where the talking is done 
face to face. 

Other vendors don’t want their technology to 
be a public-controlled standard. They lose control 
of their own specification. If they have a large 
market share, i.e. they’re a de facto standard, 
they may want nothing to do with becoming a de 
jure standard. 

Myth #3 

“Vendor TLA sells a posix conforming sys- 
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tem.” Wrong. No one sells a “posix” conforming 
system. Indeed, posix conformance is the real 
myth here. 

posix. 3 is a standard which defines the test 
methodology used to measure conformance to 
POSIX. It has recently become a standard, IEEE 
1003.3-1991. An accompanying document, still in 
the balloting process and therefore unstable, is 
POSIX.3.1. This document contains the test meth¬ 
ods themselves for posix. l, (the base system in¬ 
terface standard), which everyone refers to as 
“POSIX”. 

By definition, POSIX. 3.1 is not yet a standard, 
hence no posix. 1 conformance test suite actually 
exists. 

There is a United States government pro¬ 
curement profile of POSIX. 1 called FIPS 151-1, or 
in today’s open systems circus, simply “THE 
FIPS.” FIPS 151-1 chooses certain options within 
the standard. It even defines certain behavior that 
in the standard is left as implementation defined. 
It was written against the original posix. 1 stan¬ 
dard, IEEE 1003.1-1988, not the current one, 
(IEEE 1003.1-1990.) In fact it was written prior 
to the completion of the standard. 

In theory, nothing changed in posix. 1, be¬ 
tween 1988 and 1990, except for the reformatting 
to make it ISO acceptable, and “bug fixes”. The 
removal of cuserid() was a “bug fix”. 

Because of the obvious buying power of the 
U.S. government, most major vendors are im¬ 
plementing FIPS 151-1. It is a profile or subset of 
posix. 1. 

Test suites exist to test conformance against 
FIPS 151-1. These must use the test methods 
described in posix.3.1 (still in ballot.) One of 
them was written to an early draft of posix.3.1. 
Another was written by using the AT&T UNIX 
System V Verification Suite (SWS) as a base. 
SWS dependencies are still being discovered and 
weeded out of this one. It is quite possible to 
implement something different from the FIPS, 
which would fail the FIPS test suites miserably, 
yet would technically conform to the standard. (If 
only there was a way to prove it.) 

Myth #4 

“posix isn’t important — it’s source code 


portability that’s important.” Well, no and yes. 
One vendor is notorious for this game. 

Yes, absolutely, source code portability is 
what it’s all about. This is typically one of the 
banners that’s waved around in many people’s 
definitions of open systems. 

POSIX is a family of standards designed to 
provide source code portability. The interface was 
derived from the many UNIX system interfaces 
that existed. UNIX was/is a de facto operating 
system in many arenas. Many vendors are imple¬ 
menting the POSIX interface on their non-UNix 
derivative proprietary operating systems. 

No, posix is not UNIX. Many UNIX devel¬ 
opers mourn and despise what has happened to 
the UNIX interface. They shouldn’t. First of all, 
the base technology, which is close enough that 
they are already familiar with it, is becoming 
available on a huge installed base of technology. 
The demand will far outstrip the supply of tech¬ 
nologists familiar with it. Second, nothing is pre¬ 
venting them from continuing on in their current 
preferred environment. It is different enough that 
they can continue developing software as they 
always have. It’s just not as portable. 

There are other software development envi¬ 
ronments which ensure software portability. VMS 
on a VAX architecture guarantees portability of 
source (and executables) across the entire line of 
VAX hardware. This is fine if that’s where your 
business lays. Likewise, IBM’s SAA will provide 
similar source portability benefits across disparate 
IBM architectures. They’re really muddying the 
waters by also implementing some of the other 
“open system” interfaces on the SAA platforms. 
Again, it all depends where you, as a software 
developer, want to draw the portability line. 
POSIX is becoming the path to widest portability. 

Myth #5 

“Open systems technologies will revolution¬ 
ize the way software is developed.” Yet another 
silver bullet contestant. Does everyone remember 
the marketing hype around 4GLs? CASE? These 
are all good useful technologies. They simply 
need to be applied in their proper forum. They do 
not remove the responsibility of thought, i.e. cre¬ 
ative design, careful development, and inventive 
testing of a problem’s solution. 
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The current “promise” of open systems tech¬ 
nologies has us living in a completely networked 
corporation of resources. Applications running 
where the optimal appropriate processing re¬ 
source is. Information available everywhere at 
once, both properly protected and with its true 
location completely irrelevant. All of it interfaced 
via some wonderful intuitive graphic user inter¬ 
face. 

I do believe this is where we’re going. The 
technology is often commercially available al¬ 
ready, but with some very real constraints on it. 
Often these constraints involve how new the tech¬ 
nology is, and the lack of standardization. 

It is a great vision, but before it’s available 
in completely heterogeneous networked environ¬ 
ments, the technology has to stabilize enough for 
standards to be created. No matter how dazzling 
the technology seems to be, a standard cannot be 
wrestled onto it too early, or it becomes a straight 
jacket on the creative forces shaping it. 

Networked system administration at this 
level is in its infancy. A corporation’s information 
and application architecture is often weighted 
down in a heavy history of legacy systems. (That’s 
if the corporation can even draw its architec¬ 
tures!) These are a couple of the “minor” prob¬ 
lems that need to be dealt with before marketing 
sells the “promise” too fully. 

Conclusions 

So there they are. My five favorite myths of 
open systems standards. I’m sure this is just the 
beginning. (I don’t get to a lot of cocktail parties. 
I have small children.) 

I’d love to hear other additions to this. No 
matter how outrageous. 


POSIX.O Guide to Open Systems Envi¬ 
ronment 

Kevin Lewis <klewis@gucci.enet.dec.com> 
reports on the July 8-12, 1991 meeting in Santa 
Clara, CA: 

The July meeting of POSIX.O saw a different 
approach to the week’s work. Instead of abiding 
by the draft agenda, the group trashed it and took 


what might be called a “fish or cut bait” approach. 
posix.o looked at each major section and deter¬ 
mined whether or not it was ready for mock bal¬ 
lot, or could be made ready by the October meet¬ 
ing. 

Accomplishing the latter required individuals 
to step up to the task of editing sections during the 
meeting, with some degree of plenary review be¬ 
fore the week’s end. This required a commitment 
from the group at large to refrain from any super 
ethereal or journalistically-based editorial discus¬ 
sions. This has sometimes been hard to avoid in 
the past. The group stuck to its guns, however, 
and made a great deal of headway. 

The sections within the guide that remain 
undecided for mock ballot are: 

• networking, 

• security, 

• graphics (GKS, etc.), 

• command user interface, 

• system administration, 

• fault management. 

Should the group decide that a section is not 
ready, we will simply not include it in the mock 
ballot. It will be included in the formal ballot. 

As it currently stands, the group plans to start 
the mock ballot early in November, bringing all 
ballot comments to the January meeting. This 
appears to be very feasible. 

The posix.o project was reviewed at this 
meeting by the tcos-ss Project Management 
Committee. The review determined there was the 
need for other tcos-ss working groups to better 
coordinate with and contribute to the POSIX.O 
guide. This was mandated through an sec reso¬ 
lution. The greatest concern among the other 
standards working groups is “how in the world are 
they going to find time to do that.” The groups 
are already concerned about their current work 
loads. 

I believe that once we go through the prep¬ 
aration at the October meeting, and get into the 
mock ballot, many of the loops that are still open 
will be closed. That is not to say that there will 
be no outstanding issues, but the major concerns 
should be laid to rest. 
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Report on POSIX.2: Shell and Utilities 

David Rowley <david@mks.com> reports 
on the July 8-12, 1991 meeting in Santa Clara, 
CA: 

Summary 

posix. 2 (Shell and Utilities) Draft 11.1 closed 
its recirculation ballot on July 19. This draft was 
circulated as the 250 pages that had changed from 
Draft 11. Balloting a “changes-only” draft proved 
to be a challenge in itself. POSIX.2A (User port¬ 
ability extension) Draft 7 closed its recirculation 
ballot on August 19. 

POSix.2b has been approved after a number 
of recommendations from the Project Manage¬ 
ment Committee. The posix.2 group continued 
work on the new pax archive format. Most of the 
time was again spent in a joint meeting with 
posix.3.2 (Test Methods for posix.2) creating 
test assertions for the document. 

Background 

A brief POSIX.2 project description: 

• POSIX.2 is the base standard dealing with 
the basic shell programming language and 
a set of utilities required for the portability 
of shell scripts. It excludes most features 
that might be considered interactive. 
posix . 2 also standardizes command-line 
and function interfaces related to certain 
posix. 2 utilities (e.g., popen(), regular ex¬ 
pressions, etc.). This part of posix.2, which 
was developed first, is sometimes known as 
“Dot 2 Classic.” 

* posix. 2 a, the User Portability Extension 
or upe, is a supplement to the base stan¬ 
dard. It standardizes commands, such as vz, 
that might not appear in shell scripts, but 
are important enough that users must learn 
them on any real system. It is essentially an 
interactive standard, and will eventually be 
an optional chapter to a future draft of the 
base document. This approach allows the 
adoption of the UPE to trail Dot 2 Classic 
without delaying it. 

Some utilities have both interactive and non¬ 
interactive features. In such cases, the upe defines 
extensions from the base posix.2 utility. Features 
used both interactively and in scripts tend to be 
defined in the base standard. 


* posix. 2 b is a newly approved project which 
will cover extensions and new requests from 
other groups, such as utilities for the 
posix. 4 (Realtime) and posix. 6 (Security) 
documents. 

Together, Dot 2 Classic and the UPE will 
make up the International Standards Organiza¬ 
tion’s ISO 9945-2— the second volume of the 
proposed iso three-volume posix standard. 

POSIX.2 Status 

Resolution of posix. 2 Draft 11 ballot objec¬ 
tions was completed, and a Draft 11.1 was re¬ 
circulated. There were 900 objections received for 
Draft 11. The Draft 11.1 recirculation ballot 
closed July 19. 

This draft was circulated as a 250 page 
“changes-only” document. This is created by 
printing the document and extracting all those 
pages containing change bars. Although this saves 
paper, it makes balloting extremely difficult. The 
context of the changes is lost. Since the page 
numbers (and even some section numbers) have 
changed since Draft 11, cross referencing old 
drafts doesn’t help much. 

The intent of this technique is to physically 
demonstrate the increase in consensus by the 
smaller size of the document. Even though bal¬ 
loting is made more difficult, I agree with the 
spirit of this approach, since most of the changes 
between Draft 11 and Draft 11.1 were fairly minor 
clarifications of the wording. 

One advantage of the “changes-only” ap¬ 
proach is that it helps to prevent balloters from 
commenting on those items that have not changed 
since the last draft. This is a restriction placed on 
recirculation ballots. You can’t object to some¬ 
thing you can’t see! 

The complete Draft 11.1 document is avail¬ 
able from the IEEE for copying costs. Draft 11.2 
is already in the works, and should appear some¬ 
time in September or Ofctober. 

There have been a few requests lately to 
amend the posix.2 project’s base documents list. 
This is a list of documents which may be refer¬ 
enced when discussing existing practice issues. 
The osf’s Application Environment Specification 
(aes) is one such candidate for addition. 
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Draft 9 of POSIX.2 is currently an iso com¬ 
mittee document. The iso standards process sees 
a document move through three phases on its way 
to standardization — Committee Document, 
Draft International Standard, and finally Inter¬ 
national Standard, iso has requested the u.s. 
Member Body to forward to them another draft 
once it has become more stable. Draft 11.2 has 
been recommended for this, when it becomes 
available. 

Draft 11.3 should be out sometime in De¬ 
cember. It should be complete from a technical 
standpoint. Hal Jespersen, the posix.2 Chair, re¬ 
ported that final ieee approval of posix.2 as a 
full-use standard will be delayed until all ISO con¬ 
cerns have been addressed. This could mean post¬ 
poning the ieee posix.2 standard until the middle 
of 1992. I don’t completely understand why the 
iso concerns cannot be addressed now, through 
iso responses to the Committee Documents sent 
to them. This will no doubt be discussed heavily 
in the months ahead. 

POSIX.2a Status 

Ballot resolution for POSIX.2A (upe) Draft 6 
was completed. There were only 400 objections. 
Draft 7 was produced and recirculated, and the 
ballot closed August 19. Ballot resolution is on¬ 
going. 

The list of POSix.2a utilities is now stable. 
There should not be any additions or deletions. 
The technical content of the standard should be 
wrapped up in the first quarter of 1992. Draft 6 
of posix.2 a was submitted to iso as a proposed 
Committee Document/Proposed Draft Amend¬ 
ment (pdam) for eventual balloting as ISO 9945-2, 
Amendment 1. Due to some procedural prob¬ 
lems, it was changed to a Review and Comment 
draft. The next draft of posix.2 a will likely be 
Draft 8 , a full draft. This will also be forwarded 
to the iso, as a Proposed Draft Amendment, and 
will hopefully make it this time. Expect the ap¬ 
proval of posix.2 a as a full-use standard any¬ 
where from three to six months after posix.2. 

Project Management Committee Review 

Both posix.2 and posix.2 a are up for review 
by the Project Management Committee (pmc) in 
October. Each project will be examined to ensure 
that the work is fulfilling its mandate. 


The pmc has recommended that the proposed 
project request (par) for posix.2B deal strictly 
with new utilities. The ISO timing and formatting 
issues originally included in the scope of POSIX.2B 
were thought to be unnecessary. 

POSiX.2b will include utilities from the other 
POSIX working groups. These working groups may 
allocate chapters in the standard in a similar fash¬ 
ion to POSix. 2a. Each group retains control of its 
chapter. This is preferable to delegating the spec¬ 
ification of the utilities to the existing POSix. 2 
working group, which may not have the required 
expertise. 

One question arose from this as the work of 
other groups is integrated into POSix.2 should 
those other groups’ base documents automatically 
be added to those of POSix.2? 

New PAX Archive Format 

Work continued on the new PAX archive for¬ 
mat. No new proposals were forthcoming, and the 
group continued working in its current direction. 
The intent is to build a new archive format on top 
of the iso 1001 tape standard. The current new 
format specification does not draw a clear line 
between what is part of the ISO format, and what 
was added for pax. This will be remedied in a 
subsequent draft. 

I have reconsidered my earlier challenges to 
basing this new format on ISO 1001. It does have 
tangible benefits, and should make transferring 
tapes between non-traditional environments eas¬ 
ier. The current proposal addresses both tape and 
non-tape based formats. 

Unfortunately, the current POSIX.2 working 
group does not seem to have a great deal of 
enthusiasm for this project. Progress is slow. Un¬ 
less someone champions this new format, it may 
well stall. Mark Brown (ibm) has volunteered to 
flesh out the current draft for distribution in the 
next posix.2 mailing. 

Test Plans and Assertions 

A test plan for POSIX. 2 and posix.2 a was 
written, and submitted to POSIX. 3 .2 (Test Asser¬ 
tions for POSix. 2 ) for review. Lowell Johnson, 
POSix. 3.2 Chair, expressed some concerns over 
the linkage of the posix .2 and the posix.2 a test 
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plans. It is important that each test plan cover the 
scope of one and only one project. 

Tuesday to Friday were spent writing test 
assertions in a joint meeting between posix.2 and 
POSix.3.2 . Confusion continues to reign when 
writing assertions. There are many different as¬ 
sertion styles, and it seems to be more art than 
science. Styles range from “you know what I 
mean”, to precise, verbose, legalese. The group 
requested that the Chair (Lowell Johnson) and 
the Technical Editor (Andrew Twigger) produce 
a style guide for POSIX.3.2 assertions. The guide 
would be reviewed at the beginning of each joint 
meeting. This should greatly help the consistency 
of the assertions being produced. 

Draft 5 of POSix.3.2 is now 400 pages, and 
most of the posix.2 commands have assertions. 
The group is still intending to mock ballot the 
document after the October meeting. A few util¬ 
ities are noticeably absent: awk, lex, and 
yacc. I’m sure donations of good assertions for 
these utilities would be most welcome. 

The turnout for the joint meetings was dis¬ 
appointing. Writing test assertions is time con¬ 
suming hard work. Ideally the joint meeting time 
should be spent reviewing assertions, and clari¬ 
fying the implied interpretations of the standard. 
Unfortunately, it is difficult for members to find 
the time between meetings to write assertions. 

Writing test assertions for POSIX.2A will 
likely start in January 1992. If you thought test 
assertions for make were difficult, wait until you 
try vi! 

Report on POSIX.3: POSIX Test Meth¬ 
ods and Conformance 

Andrew Twigger <att@root.co.uk> reports 
on the July 8-12, 1991 meeting in Santa Clara, 
CA: 

In many ways the Santa Clara meeting could 
be considered to be one of the less eventful of the 
recent posix. 3 meetings. 

Draft 5 of the posix. 3.2 document was dis¬ 
tributed at the meeting, with the majority of the 
test assertions having been aligned with the text 
of POSIX.2 (Shell and Utilities) Draft 11. This 
alignment was exquisitely timed to coincide with 
the production of Draft 11.1 of POSIX. 2, imme¬ 


diately rendering parts of Draft 5 out of date! 
Perhaps the documents can be synchronized for 
the next meeting, or the one after that, or ... . 

The majority of the POSIX. 3 working group 
spent most of the meeting writing assertions with 
posix.2. Having already dealt with the “simpler” 
utilities, some of the more complex utilities 
(make, pax, Is) were tackled during the week. 
The next draft should contain assertions for about 
95% of the utilities, however the remaining 5% 
could take 95% of the time! 

The ballot review group for posix. 3.1 met 
briefly during the week to look over the objec¬ 
tions received during the last ballot recirculation. 
Most of these had been resolved prior to the 
meeting and it was expected that the remaining 
items could be resolved by the end of August. 
Another brief recirculation ballot is expected in 
the Autumn, with possibly another standard being 
completed by the end of the year. 

The Steering Committee for Conformance 
Testing (scct) met twice during the week and 
finally approved some of the test method devel¬ 
opment plans submitted by the other working 
groups. The rumour that this was only in response 
to moans from the other working groups that the 
SCCT had rejected every plan submitted in the 
previous nine months is not entirely without foun¬ 
dation! Most of the other working groups, how¬ 
ever, are getting geared up to produce test meth¬ 
ods with their documents. 

Several members of posix. 3 spent time in 
assisting other working groups to develop test 
methods, for their standards. Much of this time 
was spent in helping the working groups to un¬ 
derstand how significant a task this is and in help¬ 
ing the working groups to develop a reasonable 
strategy for test methods. Some time was also 
spent in reviewing the work that had already been 
done by work group members. There seems to be 
an increased awareness of the problems and an 
ever improving quality to the test methods that 
the working group are producing. 

Report on POSIX.4, PGSIX4a, 
POSIX4b, POSIX. 13: Realtime POSIX 

Bill O. Gallmeister <bog@lynx.com> re¬ 
ports on the July 8-12, 1991 meeting in Santa 
Clara, CA: 
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Summary 

The working group continued work on Ap¬ 
plication Profiles, on the extended POSIX.4B Re¬ 
altime Proposals, and on the thorny issues of ipc 
and synchronization mechanisms. Since both 
posix .4 and POSIX.4A are preparing for another 
ballot recirculation, there was little work done on 
these drafts. 

Real-time Application Profiles 

posix .4 has produced four different profiles, 
matching different scales of real-time endeavor. 
The Embedded profile is meant for small ma¬ 
chines that may lack hardware for paging, disks, 
and terminals. As such, this profile is rather dif¬ 
ferent than what is generally considered to be a 
UNIX® system. In particular, the threads work is 
called out, and some of the posix.i file system, 
but fork() is not needed. 

This requires subsets of posix.i. Its multi- 
process aspects and a lot of the extended file¬ 
system semantics are considered optional by the 
people working on the smaller Real-Time pro¬ 
files. This subsetting work has to be sanctioned by 
posix.i. Getting them to agree to this work may 
be an interesting task. 

Other profiles under development are a 
“Controller” profile, an “Avionics” profile, and 
the “Kitchen Sink” profile. The Kitchen Sink and 
the Embedded profiles define two endpoints of a 
spectrum of real-time practice. The Controller 
and Avionics profiles define particular points of 
practice within that spectrum. The Avionics pro¬ 
file reflects the current requirements of the Avi¬ 
onics industry. The Controller profile is a step up 
from the Embedded profile. 

IPC Again 

POSIX.4 inter-process communication (ipc) 
remains an issue. We had a liaison meeting with 
the posix .12 (Protocol Independent Interfaces) 
working group and presented our requirements 
for a Real-Time sockets mechanism. There were 
28 possible requirements; we decided that 17 of 
these requirements were truly necessary for a 
socket-based mechanism for Real-Time ipc. The 
POSIX.12 group helped us refine these require¬ 
ments into something they can use in defining a 
mechanism. These discussions will undoubtedly 
carry on for some time. 


Meanwhile, the existing posix .4 ipc chapter 
is undergoing radical surgery. The recirculation 
draft that should come out this October should 
feature an IPC mechanism that more closely re¬ 
sembles the message-passing interfaces of small 
real-time kernels. The interaction of this message¬ 
passing mechanism and the future posix.12 real¬ 
time sockets mechanism is an open issue. 

Synchronization Again 

At the last meeting, it was the POSIX.4 pro¬ 
posal that needed guidance from the working 
group on its binary semaphores chapter. This 
meeting, the POSIX.4A proposal required guid¬ 
ance with regards to mutexes. (Mutexes are sim¬ 
ple MUTually Exclusive locks.) Specifically, the 
priority ceiling protocols in the current draft ran 
into serious balloting problems. In response to 
this, a simplified version of the priority ceiling 
protocol, called Priority Ceiling Protocol Emula¬ 
tion, was proposed to replace the existing two 
mechanisms currently in POSIX.4A. The emulation 
protocol is much easier to understand, offers the 
same worst-case blocking behavior as the earlier 
proposals (although worse average-case behav¬ 
ior), and works with multiprocessor systems. The 
working group was torn whether any priority ceil¬ 
ing protocol should be in POSIX.4A at all. As¬ 
suming that one would be present, the group 
clearly preferred the emulation protocol. 

The debates on priority ceiling featured a 
lively exchange between posix .4 and posix .14 
(Multiprocessor Profile). This is the closest that 
posix .4 has come to its old glory days of large 
bloody group battles. 

POSIX.4b 

Some work was done on the timeout exten¬ 
sions of POSIX.4B. This work involves providing 
timeouts to all posix .4 calls that may block. An 
early draft of this proposal is available in the latest 
posix .4 mailing. 

Future Drafts 

The technical reviewers for posix . 4 and 
POSIX.4A have been working hard towards new 
drafts of each of these documents. It is our current 
plan to recirculate them both at about the same 
time as the Fall meeting. If this happens, the next 
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meeting will again focus on application profiles 
and continuing POSIX.4B. 

Report on POSIX.6: POSIX Security 
Extensions 

Ana Maria De Alvare <anamaria@sgi.com> 
reports on the July 8-12, 1991 meeting in Santa 
Clara, CA: 

Hello usenix members! 

This time my report will be very brief. It is 
brief because there were no big disagreements at 
the meeting, and because the whole week was 
spent in cleaning up the document for formal 
ballot. 

This was the last meeting working in func¬ 
tional subgroups, addressing discretionary and 
mandatory access controls (dac and mac), audit, 
and privileges. At the next meeting the group will 
be divided into people helping with the balloting 
process, doing test assertions, and identifying ar¬ 
eas that POSIX.6 has not covered. The ballot doc¬ 
ument should come out sometime after the Sep¬ 
tember mailing (September 10, 1991). 

POSIX.6 spent the whole week addressing all 
the mock ballot comments and objections. A 
small group of three people, including myself, 
began working on the first draft of the posix.6 test 
methods. The test methods draft will be brought 
to the next meeting and people from the dis¬ 
banded subgroups will begin creating test meth¬ 
ods for the functions defined in the posix.6 doc¬ 
ument. It will be a long week! 

So what areas aren’t covered in the current 
POSix.6 draft? The three major areas that I know 
are not covered are: 

• authentication, 

• security system administration, and 

• network security. 

There are items in the subgroups which are 
also not addressed. A portable audit format has 
not been fully defined, and so is not going out for 
ballot. With mandatory access controls, we de¬ 
cided at this meeting to not enforce privileges on 
an implementation of multi-level directories. Ex¬ 
cept for some clean-up in Draft 11, discretionary 
access controls remain the same. 

The data type issue still remains across the 


dac, mac, audit, and privileges subgroups. To 
interoperate between systems, opaque objects 
need to be stored and retrieved without concern 
for the implementation defined formats. An 
opaque object model also provides consistency 
across the interfaces, posix.6 subgroups have de¬ 
fined a number of security related objects. We 
cannot agree on a way to represent these, but 
have determined four possibilities: 

• A Type 1 object is opaque, and is only valid 
for use by the process which gets the data, 
and only for the lifetime of the process. 

• A Type 2 object is still opaque, but it must 
be self-contained and persistent. 

• A Type 3 object is a text string with an 
undetermined format, mac labels are rep¬ 
resented as Type 3 data types. 

• A Type 4 object is a text string with a 
defined format. Access Control Lists (acls) 
have a Type 4 representation. 

One compromise was that the subgroups 
would define conversion routines for Type 2 and 
3 data, which would return an opaque object and 
the length in bytes of the object. 

We were still unable to agree upon a uniform 
type representation across the four subgroups in 
the July meeting. This issue will likely be a hot 
one in the balloted document. We will have to 
wait and see what the ballot brings to resolve this. 

Well, that’s all folks! Keep an eye out for the 
posix.6 ballot. 


Report on POSIX. 12: Protocol Indepen¬ 
dent Interfaces 

Tim Kirby <trk@cray.com> reports on the 
July 8-12, 1991 meeting in Santa Clara, CA: 

posix. 12 is developing a set of protocol in¬ 
dependent networking interfaces. There were no 
major changes in the group’s direction this meet¬ 
ing. Two interfaces are proposed in language in¬ 
dependent form — the simple network interface 
(sni) and the detailed network interface (dni). 
sni is a proposal drawn from several sources, with 
no existing (de-facto) standard, dni, however, is 
seen as a single language independent specifica¬ 
tion to which there are two valid C language 
bindings, one for BSD-style sockets and one for the 
x/open Transport Interface (xti). 
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The group once again reviewed the proposed 
changes to xti option management from Gerhard 
Kieselman, following input from x/open during 
the intervening three months. 

A significant amount of time was spent in 
liaison with the Transaction Processing (posix. n) 
and Real-Time (posix.4) working groups as a 
result of the proposal from the last meeting to 
include their requirements in the POSIX. 12 inter¬ 
face. POSIX.4 requirements are a direct result of 
ballot objections to the ipc interface proposed in 
their current draft. Given the announced inten¬ 
tion of POSIX.4 to include a “simple” ipc interface 
regardless of the posix.12 efforts, there is some 
concern within our group that there are no ad¬ 
vantages to the proposed posix.12 changes. 

Work between the meetings continues on 
language independent versions of the interfaces, 
and the test methods without which the document 
may not become a standard. 

A review of the test method requirements 
revealed a significantly larger amount of work 
than had originally been anticipated. This has 
resulted in a change to the test method schedule. 
The mock ballot of the POSix.12 draft is not ex¬ 
pected now before the second quarter of 1992, 
and the first real ballot not before the fourth 
quarter of 1992. 

Report on POSIX.17 - Directory Ser¬ 
vices API 

Mark Hazzard <markh@rsvl.Unisys.com> 
reports on the July 8-12, 1991 meeting in Santa 
Clara, CA: 

Summary 

posix .17 made significant progress towards 
completing another draft in Santa Clara. The 
group is on track to mock ballot Draft 2.0 of the 
Directory Services API by the end of August. Key 
areas of progress were: 

• test methods, 

• language independence specification (lis), 

• Model text in Section 3, 

• ds_gethostbyname() example, 

• preparation for mock ballot. 

Introduction 

The posix .17 group is generating a user to 


directory API, e.g. an API to an X.500 Directory 
User Agent (dua). We are using xapia — 
x/open’s XDS specification as a basis for work. The 
x/open Directory Services API (xds) is an object- 
oriented interface and requires a companion spec¬ 
ification, x/open’s Object Management API 
(xom), for managing the osi objects as they pass 
through the directory API. 

xom is a stand-alone specification with gen¬ 
eral applicability beyond the directory services 
API. It will be used by IEEE 1224.1 (X.400 API) and 
possibly other posix groups. It is being standard¬ 
ized by IEEE 1224. 

Status 

Commitment within the group remains 
strong, with all Chicago attendees returning to 
Santa Clara, and completing homework assign¬ 
ments. We are committed to mock balloting our 
document between meeting cycles and have 
planned a special mailing for the end of August, 
(paid for by x/open - Thanks!). 

Once again, considerable time was spent ex¬ 
amining POSIX.12 (Protocol Independent Inter¬ 
faces) requirements for directory services. One of 
the requirements is a mechanism to protect ex¬ 
isting applications from changes in how directory 
services are offered. We had decided that this was 
technically beyond the scope of our work, but that 
we would address this by providing a non- 
normative annex with coding examples, showing 
how it could be done. 

The first example is a new function, dsgeth- 
ostbyname(), which could be added to the existing 
practice API (bsd’s gethostbynameQ function). 
With it (or something similar) existing applica¬ 
tions wouldn’t need to be modified to work in a 
posix environment. 

Another POSIX. 12 requirement was that the 
underlying directory service provider be able to 
interoperate/co-exist with existing practice direc¬ 
tory services (e.g. the Internet DNS). On the sur¬ 
face, impact to the API itself is minimal, requiring 
(at most) the use of an existing parameter which 
would allow the application to specify which (of 
many) services it wanted to use. 

POSix.17 and P1224 (xom API) met in joint 
session to review the object management speci¬ 
fication. Many corrections were made, and a new 
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draft will be released in the first half of August (in 
time for our Mock ballot). 

Mock Ballot 

There were many homework assignments this 
time to get the mock ballot out between meetings. 
Significant progress was made towards producing 
a draft suitable for mock ballot. The technical 
editor completed his assignment to provide 25% 
of the us text. An estimated 25% of the test 
assertions were completed as well. Our plan is to 
go to mock ballot with this level of completeness 
in order to obtain feedback before we proceed 
further. 

We plan to send it out before the end of 
August, so we’ll be able to process the feedback 
at our next meeting. Hopefully, we’ll get feedback 
on our Lis and test assertion work. The comments 
will help us determine our future direction and 
better estimate our completion date. 

In Closing 

The group made good solid progress in Santa 
Clara readying the document for mock ballot. We 
seem to uncover more requirements with each 
meeting but somehow we’re managing to move 
forward, posix .17 will be mock balloted incom¬ 
plete, needing more work on Lis, test methods 
and a few more examples. 

The group will meet in October to process 
the input from our mock ballot, continue working 
on Lis and test methods, and determine where we 
go from there. As usual, there’s a lot of work to 
do. 

Report on P1224: X.400 API 

Steve Trus <trus@osi.ncsl.nist.gov> re¬ 
ports on the July 8-12, 1991 meeting in Santa 
Clara, CA: 

Summary 

pi 224 is producing two documents for stan¬ 
dardization — the x .400 API and the X/Open 
Object Management api (xom). At Santa Clara, 
the group continued work on the modifications 
required to the base documents. Specifically the 
group: 

• reviewed the first draft of the Object Man¬ 


agement API, 

• worked on test methods, 

• worked on IEEE balloting plans for Pi 224 . 

The IEEE Standards Board has approved the 
Project Authorization Requests (pars) for pi 224 
(osi Object Management api) and pi 224.1 
(X.4OO API). 

Report 

The Santa Clara meeting was generally pro¬ 
ductive for the Pi 224 working group, and we are 
well under way to producing our draft documents 
for standardization. Progress wasn’t what it could 
have been due to minimal participation by the 
x .400 api Association. 

Review of Object Management Draft 

The first draft of the Object Management api 
was distributed to the Pi 224 working group be¬ 
fore the meeting. The group spent much of the 
week reviewing the API. The POSIX.17 (Directory 
Services) group joined the review for one day. 
Numerous changes were made to the document. 
When the changes have been incorporated into 
the document, it will again be sent out in the 
P1224 mailing. 

Test Methods 

Tony Cincotta, a test methods expert from 
NIST, spent much of the week reviewing the Ob¬ 
ject Management draft and test methods already 
developed. Tony provided many suggestions for 
improving the test methods developed thus far. 

It has become apparent that the development 
effort required to build test methods for the x .400 
and Object Management apis could delay the 
completion of balloting of the apis for years. To 
resolve this problem x/open is considering fund¬ 
ing a contractor to develop the test methods for 
these documents. This issue should be resolved by 
the next meeting. Additionally, Tony recom¬ 
mended that he train fhe x/open contractor for 
the development of the test methods section of 
the documents. 

Balloting Plans 

Our current plans are to ballot the Object 
Management API after the October meeting, and 
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to ballot the x .400 api after the January meeting. 
These ballots would not include the test methods; 
balloting cannot complete until the test methods 
are complete. 

Currently we are developing the list of people 
who will be invited to ballot these documents. 
This list includes members of the ieee tcos, the 
x .400 API Association, and x/open Limited. In¬ 
vitations to join the balloting group will be sent 
out at the end of August by the ieee. To be 
included in the balloting group, a person must 
return the invitation to the IEEE by October 10, 
1991. 

Iain Devine, the P1224 technical editor, will 
be the ballot resolution reviewer, assisted in tech¬ 
nical matters by Enzo Signore. 

In Closing 

pi 224 continues to make good progress. The 
primary focus of the Parsippany meeting will be 
to continue the review of our draft documents, 
work on our test methods, and prepare for bal¬ 
loting. 

Report on ANSI and the X3 Commit¬ 
tees 

John Hill <hill@prc.Unisys.com> discusses 
ANSI and the X3 committee: 

Over the past few years information tech¬ 
nology standards have become more important in 
the industry. One of the most prevalent areas for 
standardization is operating systems and allied 
services. This article discusses the largest formal 
standards development organization for informa¬ 
tion technology in the USA, X3, and its relation¬ 
ship to ANSI. 

A brief background is useful in understand¬ 
ing how the USA develops standards. The premier 
standards body is the American National Stan¬ 
dards Institute (ansi). Its four main functions that 
are of interest here are: 

• membership in the International Standards 
Organization (iso) and the International 
Electrotechnical Commission (iec) , the 
worldwide standards bodies, 

• accreditation of organizations to develop 
voluntary u.s. standards, 

• publication of u.s. national standards,* 


• oversight of the standards development 
process to ensure due process and fairness. 

That’s right, ansi does not develop stan¬ 
dards; ansi accredits other organizations to de¬ 
velop standards. 

Standards are developed in one of three 
ways: 

• by professional and trade organizations 
(e.g. Institute of Electrical and Electronic 
Engineers, IEEE, an organization which is 
involved in more than the development of 
standards), 

• by accredited committee (X3), 

• by canvass (e.g. Ada Joint Program Office, 
ajpo) . The canvass method is intended for 
mature and non-controversial standards 
processing. 

In a nutshell, ansi accredits the standards 
development procedures of individual groups 
within some designated, but very broad scope, 
and according to one of the three ways. X3, while 
not a part of ansi itself, is an example of a com¬ 
mittee that ansi has accredited to develop u.s. 
national standards. 

X 3 was established in 1961. Since its incep¬ 
tion, the Computer and Business Equipment 
Manufacturers Association (cbema) has func¬ 
tioned as the secretariat. X 3 has about 850 
projects, 200 standards, and some 3000 volun¬ 
teers. 

The purpose of X 3 is voluntary standardiza¬ 
tion in the areas of computers, information pro¬ 
cessing, and peripheral equipment and devices. 
This scope of activity includes standardization of 
subsystems in order to provide for hardware in¬ 
teroperability and software portability. As a re¬ 
sult, many of the fundamental standards of the 
computer industry have been developed by X3. 

The true, nuts-and-bolts work of X 3 is done 
by its subgroups. There are two types of sub¬ 
groups, advisory and technical. The three advi¬ 
sory committees are collectively empowered to 
ensure that the process of standards development 
is under control. These advisory committees are 
chartered to 

• advise the secretariat in administrative 
activities, 

• develop the X3 strategic plan, 

• manage the technical activities of X3. 
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The forty technical committees of X 3 actually 
develop the standards. There are committees for: 

• media (both magnetic and optical), 

• operating system services (database and 
graphics), 

• programming languages (Fortran, C, 
COBOL), 

• codes and character sets, 

• vocabulary, 

• data communications (osi), 

• systems technology (SCSI, security), 

• and office systems (oda/odif). 

These technical committees frequently act as 
the u.s. technical advisory groups (tags) for the 
development of worldwide standards. 

Worldwide standards are a major area of 
activity for X3. Over the past ten years, the X3 
member organizations have expended more re¬ 
sources for development of the base osi standards 
than on any other single functional area of stan¬ 
dardization. These 175 largely anticipatory stan¬ 
dards were developed for the most part in the 
international arena. The us delegates from the X 3 
technical committees actively worked in SC2I , the 
iso/iec subcommittee responsible for the OSI stan¬ 
dards, to ensure that us interests were met in the 
worldwide standards being developed. 

Membership in X 3 is open to anybody af¬ 
fected by its standards. Its current members, of 
about 41, include some of the most notable pro¬ 
ducers, users, and general interest groups in¬ 
volved in the information technology industry. 
Members have to participate in order to remain 
in good standing. 

All members pay annual service fees to sup¬ 
port X 3 activities. The larger members pay more 
than the smaller. An additional fee is charged for 
participating in the subgroups. 

If you have further questions concerning X3, 
you should contact the X 3 secretariat 
(202-737-8888). These helpful people can send 
you several standing documents which expand 
upon this discussion. 

Report on X3J16: C++ 

Mike Vilot <mjv@objects.mv.com> reports 
on the July 8-12, 1991 meeting in Santa Clara, 
CA: 


Current Status 

The ansi X3J16 committee took a major step 
towards internationalization at its June meeting. 
This was the first joint meeting between X3J16 
and iso WG2I. WG2I is the iso C++ working 
group. X3J16 and WG2I are roughly peer orga¬ 
nizations. 

June meeting 

The Lund Institute of Technology hosted the 
meeting in Sweden. The week’s major activities 
focused on understanding the myriad details of 
producing a single, international C++ language 
standard. 

The X3Ji6’s sub-groups focus was on the key 
topics listed in the goals statement developed at 
the March, 1990 meeting. They worked by elec¬ 
tronic mail between meetings, and reported their 
progress. 

International Concerns 

Steve Carter, of Bellcore, presented the ma¬ 
jor international concerns: 

International cooperation is an explicit goal 
of X3J16, and the committee devoted the entire 
first day’s discussion to international concerns. 
Most members want to avoid the difficulties en¬ 
countered during the development of the C lan¬ 
guage standard. 

Much of the work focused on attaining a 
smooth coordination with WG2I without losing 
technical effectiveness. The committee agreed to 
continue emphasizing informal discussions and in¬ 
formal “straw votes” before making formal deci¬ 
sions. All members of WG2I will be added to the 
email lists, and will receive X3J16 paper mailings. 

On the other side, WG2I voted to hold its 
technical meetings jointly with X3J16. They ap¬ 
pointed Jonathan Shopiro as their editor, which 
means both committees have the same editor. 

X3J16 decided to conduct a letter ballot on 
the question of converting to a Type “I” process. 
This means developing an international standard, 
rather than developing a domestic standard fol¬ 
lowed by an international standard (as was the 
case for the C language). A straw vote indicated 
most members would vote in favor of the change. 

The committee dissolved the International 
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Concerns working group, since it has served its 
purpose. Steve Carter, serving as Convener of 
WG2I , will continue to address international C++ 
concerns. 

Editorial 

Jonathan Shopiro, of at&t, presented the 
Editorial group’s work: 

The editorial change that simplified the treat¬ 
ment of names and name lookup, merging the 
concepts that had previously been treated under 
the topics of dominance and name hiding, re¬ 
mained in the document. 

Much of the recent work on the document 
has been in clarifying or defining basic terms. For 
example, the basic unit of storage is a byte. In the 
C standard, it is a character, which confuses the 
notion of what type “char” is supposed to rep¬ 
resent, especially in light of 8-bit and larger char¬ 
acter sets. The process of resolving the definitions 
of the two base documents continues. (These are 
the Annotated C++ Reference Manual and the C 
standard.) 

One minor change to the document format: 
the size is now suitable for A4 paper. 

Formal Syntax 

Reg Charney, of Program Conversions, pre¬ 
sented the work of the Formal Syntax group: 

The bulk of the discussion concerned the 
change that renamed most of the non-terminals in 
the grammar. There are still more proposed 
changes. 

The conflict between the virtues of regular¬ 
izing the naming versus the evils of gratuitous 
changes resurfaced. Bjarne Stroustrup made the 
strongest criticism, observing that the changes had 
been proposed and adopted without sufficient 
principles. He noted that the lack of such prin¬ 
ciples invited the kind of “random changes” that 
were presented at the June meeting. He also ob¬ 
served that the changes had not even been 
checked against the C standard’s grammar. 

Core Language 

Andy Koenig, of at&t, presented the Core 
Language group’s work: 


Most of the Core Language discussion cen¬ 
tered on name resolution issues. These issues are 
highlighted by the interactions of nested classes, 
inline friend function definitions, and static class 
members. 

This work has helped identify ambiguities in 
the present wording. Although there has been 
progress, open issues remain. For example, de¬ 
fining a friend function in a class causes the name 
of the friend to be made available in an “enclos¬ 
ing” scope. The cases involving nested and local 
classes still have to be resolved. 

Environment 

John Wilkinson, of Silicon Graphics, pre¬ 
sented the work of the Environment group: 

Discussion continued on static initialization 
order for objects in different translation units. 
The group proposed two new rules intended to 
provide correct initialization that still accommo¬ 
dated dynamic linking: 

• Nonlocal static objects defined in a trans¬ 
lation unit must be initialized in the order 
that the definitions appear in the translation 
unit. 

• The nonlocal static objects defined in a 
translation unit must be initialized before 
any object or function defined in that unit 
is used by any other translation unit; the 
nonlocal objects defined in the translation 
unit containing main() must be initialized 
before control enters main(). 

Specifying translation limits in the standard 
was discussed, but seemed to generate more heat 
than light, and nothing was decided. 

Libraries 

Jerry Schwarz, of Lucid, presented the Li¬ 
brary group’s work: 

There is an evolving proposal for a standard 
string class, and its interaction with internation¬ 
alization concerns. The tradeoff involves gener¬ 
ality (strings of both single- and multi-byte char¬ 
acters) versus efficient implementation. This 
discussion continues. 

The group also worked on issues of conform¬ 
ance, and describing the options available to im¬ 
plementations that choose to extend the standard 
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library. For example, the implementation may 
provide the standard classes by deriving them 
from base classes not mentioned in the standard, 
or as instances of templates not mentioned in the 
standard. As another example, an implementa¬ 
tion may add members to a class definition, with 
the constraint that private virtual functions must 
be in the implementation name space. 

Work also progressed on standard excep¬ 
tions. One line of investigation is to use excep¬ 
tions to clarify those aspects of the language that 
are vague or “undefined.” For example, the de¬ 
fault new_ handler could throw a storage, error 
exception. 

Language Extensions 

Bjarne Stroustrup, of AT&T, presented the 
work of the Extensions group: 

The group proposed a change that adds di¬ 
graphs and new keywords as synonyms for certain 
characters. For example, ’{’ can be written as 
’<%\ ’& = ’ as ’and_eq\ and so on. This allows 
expression of C++ programs in character sets that 
do not include certain of the ASCII characters. It 
is a proposal Bjarne has been working on with 
Keld Simonsen for over a year, and their work has 
been coordinated with the iso WG14 (C lan¬ 
guage). The committee adopted this proposal. 

The group is working through a long list of 
proposals for changes to the language. Some of 
the items are: 

• adding 8 -bit (i.e. international) characters 
in identifiers; 

• allowing virtual functions in a derived class 
to use a more specific return type than the 
base class’ version of the function; 

• allowing overloading of operator . (dot); 

• a name space control mechanism. 

The largest issue currently lurking in the Ex¬ 
tensions category is the addition of support for 
run-time type information. There will be much 
discussion on this topic over the next months. 

C Compatibility 

Tom Plum, of Plum-Hall, presented the work 
of the C Compatibility group: 

The group continued its investigation of the 
vocabulary differences between C and C++ . Only 


a few of the differences have been resolved, and 
Tom plans to meet with Jon Shapiro to decide 
which terms can be incorporated as C++ defini¬ 
tions. 

Forthcoming events 

The next three x3J16 1991 meetings (and 
their hosts) will be: 

• November 11-15, Austin TX (TI) 

• March 9-13 (or 16-20) 1992, London, UK 
(BSI and Zortech) 

• July 13-17 Toronto Canada (IBM) 

Membership on an X 3 committee is open to 
any individual or organization with expertise and 
material interest in the topic addressed by the 
committee. The cost for voting or observer mem¬ 
bership is $250. Contact the chair or vice chair for 
details. 

Chair: Dmitry Lenkov 

HP California Language Lab 

19447 Pruneridge Avenue MS 47 le 

Cupertino, ca 95014 

(408)447-5279 

fax (408)447-4924 

email: dmitry%hpda@hplabs.hp.com 

Vice Chair: William M. Miller 

Glockenspiel, Ltd 

P.O. Box 366 

Sudbury, ma 01776-0003 

(508)443-5779 

email: wmm@world.std.com 

Report on ANSI X3B11.1: WORM File 
Systems 

Andrew Hume <andrew@research.att.com> 
reports on the July 8-12, 1991 meeting in Murray 
Hill, NJ: 

Introduction 

X 3 BII .1 is working on a standard for file 
interchange on random access, write-once media: 
a portable file system for worms. First let me 
apologize for tardy snitching (again); my excuse 
this time is that I am now technical editor of the 
working paper. I shall describe the results of the 
last two meetings, April (North Falmouth, Ri) and 
July (Colorado Springs, co), as a summary of 
where we are now. In brief, the current draft 
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seems fairly stable and we expect to conduct a 
letter ballot after the next (October) meeting. 
There is also considerable international activity. 

I also discuss our method of electronically dis¬ 
tributing our drafts. 

International Activity 

I am still a novice at international standards 
stuff so take the following with a larger than 
normal grain of salt. 

The appropriate iso committee, SCI5, has 
been reconstituted and had its first meeting in 
several years in July in Tokyo. The meeting was 
mostly administrative in nature but there was a 
proposal for a volume structure standard submit¬ 
ted by Fujitsu. The motivation for this is that 
Fujitsu intends to introduce 3.Sin media and 
drives that can be partially embossed (like CD- 
rom) and partially WORM or rewriteable. Under¬ 
standably, they would like to have a standard 
volume labelling scheme to enhance interchange. 
They figure that file system layout standards can 
come along later but we need the volume labelling 
scheme real soon now. 

A common way for an iso committee to do 
work is invite some recognized, accredited com¬ 
mittee to submit a proposal and then vote on it. 
In particular, some committee with relatively little 
administrative procedure. This means ecma, (Eu¬ 
ropean Computer Manufacturers Association,) 
and not ansi. 

Luckily, the relevant ecma committee, TCI5, 
has just been reconstituted with its next meeting 
in Geneva in early September. Ostensibly, TCi5’s 
first job is to consider and bless the work of the 
Frankfurt group, which has been working on an 
extension of iso 9660 (cd-rom) to handle cd-wo 
media. The very next thing will probably be a 
volume structure and file system standard, based 
on our (X3BH.1) work. (This has required signif¬ 
icant changes to our working paper but more on 
that below.) 

There is also a dark side to TC15. ecma 
apparently has a hidden agenda for TC15 that 
includes the development of a general storage 
architecture. This is the storage equivalent of the 
osi networking model with its 7 layers. The first 
guess at the layers are: 


• physical layer, 

• recording layer, 

• formatting layer, 

• volume structure layer, 

• object management/file system layer (e.g. 

iso 9660), 

• file structure layer (e.g. ISAM), 

• application layer. 

Why does the international activity matter? 
(That this question needs to be raised is comment 
enough for our industry.) The goal of the stan¬ 
dards game is to have a technically sound standard 
adopted as soon as possible. Assume for now that 
the X3BH.I draft is technically sound. How do we 
get a standard? One way is to go through ansi 
procedure, like the C standard did. Assuming no 
problems, hitches, objections and foulups, we 
could have an ANSI standard within two years. 
And then we would have to work within the 
ecma/iso committees to ensure that they adopt a 
technically equivalent standard (and thus avoid 
the prospect of an ansi standard that conflicts 
with an iso standard). The other way is to work 
within the ecma committee and produce an ecma 
standard which then, given the heavy European 
presence in iso, would fairly automatically be¬ 
come an iso standard. Astonishingly enough, it 
seems likely that we could get an iso standard 6-9 
months sooner than we could get an ansi stan¬ 
dard! (Yes, sadly, this means that often the quick¬ 
est way to get an ansi standard is to do the iso 
standard via ecma and have ansi adopt the iso 
standard.) 

The Current Draft Working Paper 

In order to facilitate adoption of the working 
paper by TC 15 , we have made several structural 
changes to the working paper. It is now in four 
parts. The first part is introductory. It specifies the 
scope and defines terms. The second part de¬ 
scribes a volume labelling scheme. It specifies how 
volumes are labelled, how partitions are defined, 
how volumes are grouped into volume sets and a 
bad sector replacement scheme. The third part 
.describes a file system layout that is independent 
of the details of part two. The fourth part is a 
short section detailing the (very few) changes 
needed to make part three suitable for rewriteable 
media. This restructuring was a significant labour, 
although it involved negligible technical change. 
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Volume/Partition Structure 

This part is probably the most changed since 
my last report. It has become much simplified and 
made independent of the file system specification. 
It handles space allocation for the volume, re¬ 
cording of volume and partition descriptors, def¬ 
initions of partitions, and bad-block mapping. 
Provision has been made for specifying the type 
of file system in a partition. Some of these will be 
predefined, such as iso 9660 and 9223. Others can 
be registered, such as proprietary formats like 
sgi’s efs file system. 

File System 

This has been fairly stable although many 
details have been tweaked. The space manage¬ 
ment within a partition and integrity controls (es¬ 
sentially the dirty bit for a partition) have been 
moved out of the volume description and into the 
file system description as it was deemed too com¬ 
plicated to demand that everyone support it. 

Technical Editing 

Because of the previous technical editor’s 
health problems, I was appointed technical editor. 
This has been quite entertaining for me; I have 
never been involved in such a complicated doc¬ 
ument production (and all of it my own doing!). 
A single processing pass produces a table of con¬ 
tents, an index, automatically generated data 
structure layouts, ansi C declarations of all the 
data structures, an ansi C program that tests that 
the declarations are correct on your system (the 
fields have the correct offsets and sizes), and last 
but not least, the troff output. 

Each pass runs at least 8 awks, 4 sorts , 10 
serfs, 2 uniq , spell , tbl, eqn , troff and Kernighan 
and Van Wyck’s balancing page makeup backend. 
It takes 6 minutes clock time on an 80 mips SGI 
multiprocessor. (This may not be a game for pdp- 
11 s anymore but at least I know what to do with 
all those cycles!) We iterate until nothing changed 
since the last pass. 


A more noteworthy accomplishment (other 
than writing more awk scripts than you can point 
an editor at) is that the current draft of the work¬ 
ing paper is available online by both ftp and email 
{netlib). You can get either of two forms: Post¬ 
Script and the troff input (minus all the formatting 
directives). This way you can print your standard 
and grep it too. The files are x3bll.l-wp.ps 
and x3bll. 1-wp. text and are in the direc¬ 
tory research/memo. For ftp , login as netlib on 
research.att.com. 

Finale 

What can, or should, you do? Well, the worst 
case is that a standard based closely on the current 
draft will become an iso standard for interchange 
for all random access disk drives (optical and 
magnetic). You not only would have to support 
it; you may also have to boot off such a disk. 

If you wish to comment on the draft, the best 
time would probably be in early November during 
the letter ballot. (You of course can’t be in the 
letter ballot because you aren’t a member, but 
you could give your comments to me.) 

If you would like more details on X3Bii.i’s 
work, you should contact either me 
(andrew3research.att.com, 908-582- 
6262) or the committee chair, Ed Beshore. I think 
the two most useful documents are the current 
draft of the working paper (about 60 pages) and 
a programmer’s guide to the draft (about 12 pages 
written by me). I will send you copies of the latter 
document; requests for other documents or more 
general inquiries about X3Bli.i’s work would be 
best sent to Ed Beshore. 

The next meeting is in Merrimack, nh on 
October 21-25, 1991. Anyone interested in at¬ 
tending should contact either me or Ed Beshore 
(edb3hpgrla.hp.com). 
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4.3BSD MANUAL REPRODUCTION AUTHORIZATION and 


OKin.K I’ORM 


Date: 


Pursuant to the copyright notice as found on the rear of the cover page of the UNIX® /32V 
Programmer's Manual stating that: 

"Holders of a UNIX ®/32V software license are permitted to copy 
this document, or any portion of it, as necessary for licensed 
use of the software, provided this copyright notice and statement 
of permisssion are included," 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and 
provide me with such copies of the Berkeley 4.3BSD Manuals as I may request. 


Signature:. 


The prices below include shipping (via UPS) and handling charges for domestic an d Canadian orders. 


4.3BSD User's Manual Set (3 vols) 

4.3BSD Programmer's Manual Set (3 vols) 
4.3BSD System Manager's Manual (1 vol.) 


Discounts are available for bulk orders. Please inquire. 


at $28.00 each = $ 

Overseas Postage only 
+ $35. each 

at $28.00 each = $ 

+ 35. each 

at $12.00 each = $ 

+ 16. each OR 

Total = $ 

+ 62. complete set 



PAYMENT OPTIONS 


I | Check enclosed payable to USENIX Association. □ Purchase order enclosed.* 
| | Please charge my: Q Visa Q MasterCard 


Account # 


Expiration Date 


Signature 


* Outside the U.S.A.? Pre-payment is required in U. S. currency by one of the following: 

* Charge (VISA, MasterCard, or foreign equivalent) 

* International postal money order 

* Check -issued by a local branch of a U.S. Bank 


9/91 


Ship to: 


Bill to, if different: 


Phone: 


Mail your check or purchase order with this order form to: 
USENIX Association, Manual Order Dept. 

2560 Ninth Street, Ste. 215 


Berkeley, CA 94710 
510/528-8649 
FAX 510/548-5738 


PLEASE ALLOW 3 WEEKS FOR RECEIPT OF YOUR ORDER. 


September/October 1991 
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() R n I R I O l< VJ 


OUT-OF-PRINT PROCEEDINGS 

The Association has photocopied, bound sets of the following past workshop and conference pro¬ 
ceedings. 


FOREIGN 


QTY 

CONFERENCE 


PRICE 

POSTAGE 

TOTAL 


San Francisco 

1988 Summer 

$29 

$20 

$ 


Dallas 

1988 Winter 

26 

15 

$ 


Phoenix 

1987 Summer 

35 

20 

$ 


Atlanta 

1986 Summer 

37 

20 

$ 


Denver 

1986 Winter 

25 

15 

$ 


Portland 

1985 Summer 

45 

25 

$ 


Dallas 

1985 Winter 

15 

10 

$ 


Salt Lake City 

1984 Summer 

29 

20 

$ 


Washington, D. C. 

1984 Winter 

25 

15 

$ 


Toronto 

1983 Summer 

32 

20 

$ 

— 

San Diego 

1983 Winter 

28 

15 

$ 


WORKSHOP 






Systems Admin. Ill 

1989 Austin 

13 

9 

$ 

__ 

Systems Admin. II 

1988 Monterey 

8 

5 

$ 

__ 

Systems Admin. I 

1987 Philadelphia 

4 

5 

$ . 


UNIX Security 

1988 Portland 

7 

5 

$ 

_ 

Graphics III 

1986 Monterey 

10 

5 

$ 

-- 

Graphics II 

1985 Monterey 

7 

5 

$ 


Total price of Proceedings _ 

Calif, residents add 8.25% sales tax _ 

Total foreign postage _ 

* Discounts are available for bulk orders. Please inquire. Total enclosed $. 


PAYMENT OPTIONS 

CD Check enclosed payable to U5ENIX Association, 
CD Please charge my: CD Visa I D MasterCar^ 


□ 


Purchase order enclosed. 



Account#___ Exp.Date 

Signature _____ 


Outside the USA? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 


Shipping Information 


9/91 


Orders to U.S. and Canada are shipped via printed matter. Please allow 2-3 weeks for delivery. Foreign orders are 
shipped via air printed matter. 


Ship to: 


Please mail this order form to: USENIX Association 

Suite 215 

2560 Ninth Street 

Berkeley, CA 94710 


2560 Ninth Street • Suite 215 • Berkeley, CA • 94710 


510/528-8649 


FAX 510/548-5738 • office@usenix.org 
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CONFERENCE 


WORKSHOP PROCEEDINGS 


Proceedings 

Member 

Price 

Non-Member 

Price Total 

Foreign 

Postage 

Nashville Conference 

June '91 

$32 

$38 

$ 

_ $22 

Dallas Conference 

Jan. '91 

28 

34 

$ 

_ 18 

Anaheim Conference 

June '90 

22 

22 

$ 

_ 15 

Washington DC Conference 

Jan. '90 

25 

25 

$ 

__ 15 

Baltimore Conference 

June ’89 

20 

20 

$ 

_ 15 

San Diego Conference 

Feb. '89 

30 

30 

$ 

__ 20 

Distributed & Multiprocessor Sys. (SEDMS) II 

Mar '91 

30 

36 

$ 

__ 20 

Distributed & Multiprocessor Sys. Workshop 

Oct. '89 

30 

30 

$ 

_ 20 

Mach Workshop 

Oct. '90 

17 

20 

$ 

_ 9 

Large Installation Sys. Admin. V Conference 

Sept. '91 

20 

23 

$ 

_ 11 

Large Installation Sys. Admin. IV Conference 

Oct. ’90 

15 

18 

$ .. 

_ 8 

UNIX Security II Workshop 

Aug.'90 

13 

16 

$ 

_ 8 

C++ Conference 

Apr. '91 

22 

26 

$ 

_ 11 

C++ Conference 

Apr. '90 

28 

28 

$ 

18 

C++ Conference 

Oct’88 

30 

30 

$ 

_ 20 

C++ Workshop 

Nov/87 

30 

30 

$ 

_ 20 

UNIX Transaction Processing Workshop 

May ’89 

12 

12 

$ 

8 

Software Management Workshop 

Apr. ’89 

20 

20 

$ 

_ 15 

UNIX and Supercomputers Workshop 

Sept. '88 

20 

20 

$ 

_ 10 

Graphics Workshop V 

Nov. '89 

18 

18 

$ 

_ 10 

Graphics Workshop IV 

Oct. '87 

10 

10 

$ 

_ 15 

Washington DC Conference 

Jan. '87 

L 10 

10 

$ 

_ 20 


* Discounts are available for bulk orders. Please inquire. 

PAYMENT OPTIONS 

EH Check enclosed payable hi USE NIX Association. EH Purchase order enclosed. 

O Please charge my: |_ I Visa L_ MasterCard 


Total price of Proceedings 

Calif, residents add 8.25% sales tax _ 

_ To tal foreign postage _ 

Total enclosed $_ 


Account # 


Exp.Date _ 


Signature _ _ 

* Outside the USA? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 


Shipping Information 

Orders to U.S. and Canada are shipped via printed matter. Please allow 2-3 weeks for delivery. Overseas orders are 
shipped via air printed matter. 

Ship to* _ Please mail this order form to: 


USENIX Association 
2560 Ninth Street 
Suite 215 

Berkeley, CA 94710 


2560 Ninth Street • Suite 215 • Berkeley, CA • 94710 • 510/528-8649 • FAX 510/548-5738 • office@usenix.org 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a new 
group and publishing information on local groups in ;login:. At least one member of the group must 
be a current member of the Association. Send additions and corrections to login@usenix.org. 


CA - Fresno: the Central California UNIX Users 
Group consists of a wucp-based electronic mailing 
list to which members may post questions or in¬ 
formation. For connection information: 

Educational and governmental institutions: 
Brent Auernheimer (209) 278-4636 

brent@CSUFresno.edu or csufres!brent 

Commercial institutions or individuals: 

Gordon Crumal (209) 251-2648 

csufreslgordon 


CA - Irvine: the UNIX Users Association of 
Southern California meets the 2 nd Monday of 
each month. 

Rich Bergstedt (714) 582-0768 

26755 Dulcinea 

Mission Viejo, CA 92691 

attmail. com! bergstedt 


Tony Becker 
mcrsysltony 

Ed Gallizzi, Ph.D. 
e. galizzi@comtmail. com 

Jay Ts 

uunet! pdn! tscs! metran! j ay 
Bill Davis 

bill@ccd. harris. com 


(813) 799-1836 
(813) 864-8272 
(813) 979-9169 
(407) 242-4449 


FL - Orlando: the Central Florida Unix Users 
Group meets the 3 rd Thursday of each month. 

Mike Geldner (407) 862-0949 

codas!sunfla!mike 

Ben Goldfarb (407) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (407) 869-2462 

{codas, attmail}! mikel 


CO - Boulder: the Front Range UNIX Users 
Group meets monthly at different sites. 

Steve Gaede gaede@sda.com 

Software Design (303) 444-9100 

&Analysis, Inc. 

1113 Spruce St., Ste. 500 
Boulder, CO 80302 


GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta Unix Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Mark Landry (404) 365-8108 


FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2 nd Tuesday of each 
month. 

Tony Vincent, John McLaughlin (305) 776-7770 
{sun ,novavax ,gould}! sun vice! tony 
jmclaughlin@sun.com 

John O’Brien (305) 475-7633 

gatech! uflorida! no va vax! j ohn 


FL - Western: The Florida West Coast UNIX 
Users Groups meeting the first Thursday of every 
month. 

Richard Martino (813) 536-1776 


MI - Detroit/Ann Arbor: The SouthEastern Mich¬ 
igan Sun Local Users Group meets jointly with 
the Nameless UNIX Group on the 2 nd Thursday of 
each month in Ann Arbor. 

Steve Simmons home: (313) 426-8981 

scs@lokkur.dexter.mi.us office: (313) 769-4086 

K. Richard McGill Bill Bulley 

rich@sendai.ann-arbor.mi.us web@applga.uucp 


MI - Detroit/Ann Arbor: dinner meetings the 1 st 
Wednesday of each month. 

Linda Mason (313) 855-4220 

michigan!/usr/group 

P.O.Box 189602 

Farmington Hills, MI 48018-9602 
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MN - Minneapolis/St. Paul: meets the 1 st Wednes¬ 
day of each month. 

UNIX Users of Minnesota Robert A. Monio 
17130 Jordan Court pnessutt@dmshq.mn.org 
Lakeville, MN 55044 (612) 220-2427 


MO - St. Louis: 

St. Louis UNIX Users Group Eric Kiebler 

Plus Five Computer Services plus5!sluug 

765 Westwood, 10A (314) 725-9492 

Clayton, MO 63105 


NE - Omaha: meets monthly, 
/usr/group/nebraska Phillip Allendorfer 

P.O. Box 31012 

Omaha, NE 68132 (402) 423-1400 


New England - Northern: meets monthly at dif¬ 
ferent sites. 

Peter Schmitt 

Peter.Schmitt@dartvax!dartmouth.edu 
Kiewit Computation Center (603) 646-2085 
Dartmouth College 
Hanover, NH 03755 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Peter J. Holsberg mccclpjh 

Mercer County (609) 586-4800 

Community College 
1200 Old Trenton Road 
Trenton, NJ 08690 


NY - New York City: Unigroup of New York City 
meets every other month in Manhattan. 

Unigroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 

peterg@murphy.com 


OH - Columbus: The Columbus Local UNIX 
Group meets the 1 st Monday of each month. 

Mark Verber verber@mps.ohio-state. edu 

Physics Department (614) 292-8002 

Ohio State University 
Columbus, OH 43210 


OK - Tulsa: the Tulsa UNIX Users Group, $USR, 
meets the 2 nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tulsix! smason @ drd. com 

Mark Lawrence (918) 743-3013 

mark@drd.com 


TX - Austin: CACTUS meets the 3 rd Thursday of 
each month. 

Capital Area Central Texas UNIX Society 
P.O. Box 9786 
Austin, TX 78766-9786 
officers@cactus. org 

James Johnson (512) 331-3781 

president@cactus.org 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
660 Preston Forest, Suite 177 
Dallas, TX 75230 

Kevin Coyle (214) 991-5512 

kevinc@shared.com 


TX - Houston: the Houston UNIX Users Group 
(Hounix) meets the 3 rd Tuesday of each month. 

Hounix answering machine (213) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb @hounix. uucp 


WA - Seattle: meets monthly. 

Bill Campbell (206) 947-5591 

Seattle Unix Group Membership Information 
6641 East Mercer 
Mercer Island, WA 98040-0820 
bill@celes tial. com 


Washington, D.C.: meets the 1 st Tuesday of each 
month. 

Washington Area UNIX Users Group 
9811 Mallard Drive 
Laurel, MD 20708 

Alan Fedder (301) 953-3626 


CANADA - Toronto: 

Evan Leibovitch (416) 452-0504 

143 Baronwood Court evan@telly.on.ca 

Brampton, Ont. Canada L6V 3H8 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


SECOND CLASS 
APPLICATION PENDINi 
at Berkeley, CA and 
additional offices 


Postmaster: Send address changes to USENIX Association, 2560 Ninth Street, Ste. 215, Berkeley, CA 94716 


Mach Program 
Standards Activities 
Micro-Kernels Workshop 



